From owner-freebsd-current Sat Dec 30 12:08:02 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA11085 for current-outgoing; Sat, 30 Dec 1995 12:08:02 -0800 (PST) Received: from haywire.DIALix.COM (news@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA11050 for ; Sat, 30 Dec 1995 12:07:56 -0800 (PST) Received: (from news@localhost) by haywire.DIALix.COM (sendmail) id EAA25743 for freebsd-current@freebsd.org; Sun, 31 Dec 1995 04:07:50 +0800 (WST) Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-current@freebsd.org Date: 31 Dec 1995 04:07:45 +0800 From: peter@haywire.dialix.com (Peter Wemm) Message-ID: <4c466h$p4b$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: (Gene, Stark), <199512271447.JAA16464@starkhome.cs.sunysb.edu> Subject: Re: Tick, tock, adjust the clock Sender: owner-current@freebsd.org Precedence: bulk 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