Date: Mon, 18 Sep 1995 22:10:26 +1000 From: Bruce Evans <bde@zeta.org.au> To: freebsd-hackers@FreeBSD.org, mal@aristotle.algonet.se Subject: Re: xntpd (or kernel) timekeeping problem? Message-ID: <199509181210.WAA23027@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>I configured my machine to run xntpd about a month ago (running ~2.0.5). >The error in the system clock frequency was to large for ntp to lock it. >After changing the tickadj args to "-q -t 9995 -a 5" it locked fine with >a drift around 50 ppm. Today I updated all of my binaries (including kernel) >to a fresh 2.1-stable version, and ntp still seems to like the 500 ppm hack >(i.e. the new values in ntp.drift still are around 50 ppm with the tickadj >args above). >Is this a problem in xntpd or the kernel? It is a bit suspicius that hacking >tickadj exactly one tick makes the drift very low... The problem is that the oscillator driving the 8254 clock is not very accurate. On your machine it is apparently wrong by about -5us per clock interrupt (about 5 8254 cycles), but fortunately it doesn't drift very much. On one of my machines it is wrong by about +8us per clock interrupt while on another it is wrong by about -3us. The best fix is to calibrate the maximum counts in isa/clock.c with reference to an accurate clock (harclock_max_count should be about 11937 instead of 11932 on your machine). Calibration is hard to do since there is no generally available accurate clock. ISA systems have another clock (the RTC) of unknown accuracy. On my machines it seems to be more accurate and just as stable as the 8254 clock. Using tickadj introduces a consistent error in microtime() near clock interrupts. Next year's machines, if not this year's, should be able to call gettimeofday() twice within 5us. Then they will see the time go backwards if `tickadj -t 9995' is used. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509181210.WAA23027>