John wrote:
On Mon, Jan 17, 2005 at 03:05:22PM -0600, Kevin Kinsey wrote:
John wrote:
OK - on my FreeBSD 5.3-STABLE system, as I have documented (cf:
message thread Re: ntpd problems since upgrading to 5.3), ntpd
won't run, even with an identical configuation to the 5.2.1 system
next to it. Furthermore, when I run adjkerntz -a, it totally whacks
the system's ability to keep time - it races forward at quite a
high rate. ntpdate runs, and sets the time correctly.
At one point, something managed to get the timekeeping parameters
pretty near normal - less than a second of drift per hour (much
better than the 40% rate it is now - it gains about 24 seconds PER
MINUTE). Then I ran adjkerntz -a again, just to see if it really
was the culprit. It does seem that it is adjkerntz that is causing
(or triggering) the problem, but now I can't get the system back
to a decent time-keeping rate. Whatever it was I stumbled across
before, I'm not finding it again now.
Now, it doesn't appear that adjkerntz itself has changed in YEARS,
so it must be some change in the system call operation, parameters,
or data structures that is causing this.
So - since I don't seem to be able to stumble across what I did
right before to get the timekeeping somewhat near normal, I am
wondering if there's a manual way to reach them.
I read through the cited thread, and don't see any replies;
nor do I see enough explanation to give you any magic
beans. Of course, I'm no one's fairy godmother...
LOL! No - I don't expect you to be - that'd take ALL the challenge
out of it!
the clock on my 5.3-STABLE system is RACING.
It is going at almost twice as fast as real time.
Hmm, that might mean something. What do you get from:
sysctl -a | grep timecounter
I don't know what all this means, but here it is...
kern.timecounter.stepwarnings: 0
kern.timecounter.nbinuptime: 37254938
kern.timecounter.nnanouptime: 0
kern.timecounter.nmicrouptime: 3040
kern.timecounter.nbintime: 19671985
kern.timecounter.nnanotime: 2982761
kern.timecounter.nmicrotime: 16689224
kern.timecounter.ngetbinuptime: 0
kern.timecounter.ngetnanouptime: 318046
kern.timecounter.ngetmicrouptime: 14256461
kern.timecounter.ngetbintime: 0
kern.timecounter.ngetnanotime: 0
kern.timecounter.ngetmicrotime: 3461614
kern.timecounter.nsetclock: 87
kern.timecounter.hardware: TSC
kern.timecounter.choice: TSC(800) i8254(0) dummy(-1000000)
kern.timecounter.tick: 1
Are these all documented somewhere? I'm sure they must be, but
I don't know where to look...
I dunno; my first guess would be sysctl(8), but I don't see
that every knob is mentioned.
I've experienced a "racing" clock on some mobos (but mostly
older ones<?>) with 5.X --- I don't remember it with 4.X, but
I've set up many more 5.X boxes now.
Setting the kern.timecounter.hardware sysctl to i8254
fixed a "racing" situation for me. After that, things settled
down a bit, and finally ntpd could sync up with its master.
It was quite unsettling, because my secretary's time records
and emails were coming to me anywhere from 4 hours to 3 days
in the future until we figured out what was going on. So, just
a thought, but you might try, as root:
# sysctl kern.timecounter.hardware=i8254
YMMV, of course. If it makes things worse, you'd go back
to TSC in a similar manner. If it helps, add this line:
kern.timecounter.hardware=i8254
to /etc/sysctl.conf.
Kevin Kinsey
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
