From owner-freebsd-current Thu Dec 28 02:43:18 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA27180 for current-outgoing; Thu, 28 Dec 1995 02:43:18 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA27169 for ; Thu, 28 Dec 1995 02:43:05 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA25874; Thu, 28 Dec 1995 21:36:29 +1100 Date: Thu, 28 Dec 1995 21:36:29 +1100 From: Bruce Evans Message-Id: <199512281036.VAA25874@godzilla.zeta.org.au> To: gene@starkhome.cs.sunysb.edu, peter@haywire.dialix.com Subject: Re: Tick, tock, adjust the clock Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk >>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