Date: Thu, 28 Dec 1995 21:36:29 +1100 From: Bruce Evans <bde@zeta.org.au> To: gene@starkhome.cs.sunysb.edu, peter@haywire.dialix.com Cc: current@freebsd.org Subject: Re: Tick, tock, adjust the clock Message-ID: <199512281036.VAA25874@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>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. Note that this method doesn't work on 586's. The tick length is now given by the macro CPU_THISTICKLEN(tick) instead of plain `tick', and on 586's the `tick' arg to the macro is ignored. A similar effect can be obtained by adjusting `i586_ctr_rate' instead of `tick', but it would be better in all cases to adjust the 8254 clock's maximum count so that clock interrupts occur every 10000 +- 0.5 ideal ticks. Then `tick' wouldn't need to be adjusted. >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. I knew that settimeofday() doesn't work right. After setting the time, the time may be up to 9999 usec later due to a residual count in the timer registers. However, this is probably unimportant, since settimeofday() is only useful for getting somewhere near the correct time. Now I know of other bugs in microtime(): - The timer registers are apparently read too fast on some systems. This may cause errors of +- 60000 usec. - Adjustments to `tick' are not compensated for. If `tick' is about 10000 +- 6, then current machines are fast enough for times to appear to go backwards. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512281036.VAA25874>