Date: 31 Dec 1995 04:07:45 +0800 From: peter@haywire.dialix.com (Peter Wemm) To: freebsd-current@freebsd.org Subject: Re: Tick, tock, adjust the clock Message-ID: <4c466h$p4b$1@haywire.DIALix.COM> References: (Gene, Stark), <199512271447.JAA16464@starkhome.cs.sunysb.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
gene@starkhome.cs.sunysb.edu (Gene Stark) writes:
>>>These step adjustments are extremley annoying to programs that run
>>>and clock things in the 10ms range. The clock jumps forward and
>>>backward like a jumping bean. If I discontinue running xntpd my
>>>time adjustment problems go away, but then my clock doesn't keep
>>>correct time.
>>
>>>Any ideas or fixes? Any good starting places to start hacking away to fix
>>>this?
>>
>>I've had the same problem for quite some time.. On all the
>>FreeBSD machines I have access to, the xntpd oscilates very very badly
>>(like you've shown) and eventually logs "not logging any more time
>>steps" or something like that.
>I solved this problem (on 486 systems) by using tickadj to adjust the value
>of "tick" a few notches off of its standard value of 10000. The values I had
>to use were obtained by trial and error, and are different on each system.
>For example, I recall having to use values like 9994 instead of 10000.
>I also use a driftfile to avoid the lengthy resync period when the system
>is rebooted.
>Changing the tick value causes the system time to increment at a different
>rate. This gets the drift rate of the clock into a region where
>xntpd can sync to it with slew adjustments rather than step adjustments.
>I still have a nagging suspicion that there is a problem with the timekeeping
>code, since on forty-some systems I never had to use a tick value above
>10000, only below. This suggests systematic bias, probably in software.
>However at one point Bruce Evans assured me that he believed the stuff was
>working correctly, so I haven't investigated further.
> - Gene Stark
Well, I've found an answer that totally cures it for us.. I increased
the 'tickadj' rate from 5us to 40us.. ie: tickadj -a 40
pwroot@gecko2[3:35am]~-101# tickadj
tick = 10000 us, tickadj = 40 us
calculated hz = 100.00 Hz
recommended value of tickadj = 5 us
And after a few days of running, behold! It has locked in!
pwroot@gecko2[3:34am]~-100# xntpdc -p
remote local st poll reach delay offset disp
=======================================================================
=tictoc.dap.CSIR 192.203.228.5 1 1024 357 0.24709 0.005590 0.03264
*murgon.cs.mu.OZ 192.203.228.5 1 1024 377 0.10953 0.078037 0.03770
[ /etc/ntp.drift: -460.729 0 (!?!)]
And after doing the same on jhome:
peter@jhome[3:12am]~src/gnu/usr.bin-126> xntpdc -p
remote local st poll reach delay offset disp
=======================================================================
*gecko2.DIALix.C 192.203.228.69 2 1024 377 0.17325 0.013486 0.02042
=perth.DIALix.oz 192.203.228.69 3 1024 377 0.18427 0.024247 0.01062
=gecko.DIALix.oz 192.203.228.69 3 1024 377 0.20697 0.016953 0.01904
[ /etc/ntp.drift: -275.651 0, also this is over a modem.]
Neither of these machines has *ever* reached a 'poll' of 1024.
The 'previous adjustment didn't complete' syslog message is also gone
now.
The question is.. what have I done? :-) Have I simply made the kernel
respond to adjtime() faster?
Which makes me wonder about the 'prev adjustment didn't complete'
messages.. Doesn't xntpd "know" how long the adjustments are meant to
take? (it records the tickadj rate when it starts up) Perhaps there
is a bug somewhere in that the adjtime() settings are taking effect
much slower than they should be? (meaning the clock is drifting
faster than adjtime?)
-Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4c466h$p4b$1>