From owner-freebsd-hackers Mon Sep 18 05:19:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA13822 for hackers-outgoing; Mon, 18 Sep 1995 05:19:30 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA13817 for ; Mon, 18 Sep 1995 05:19:19 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id WAA23027; Mon, 18 Sep 1995 22:10:26 +1000 Date: Mon, 18 Sep 1995 22:10:26 +1000 From: Bruce Evans Message-Id: <199509181210.WAA23027@godzilla.zeta.org.au> To: freebsd-hackers@FreeBSD.org, mal@aristotle.algonet.se Subject: Re: xntpd (or kernel) timekeeping problem? Sender: owner-hackers@FreeBSD.org Precedence: bulk >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