From owner-freebsd-current Tue Oct 31 23:28:24 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA28443 for current-outgoing; Tue, 31 Oct 1995 23:28:24 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA28425 ; Tue, 31 Oct 1995 23:28:04 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id SAA20983; Wed, 1 Nov 1995 18:23:37 +1100 Date: Wed, 1 Nov 1995 18:23:37 +1100 From: Bruce Evans Message-Id: <199511010723.SAA20983@godzilla.zeta.org.au> To: gibbs@freefall.freebsd.org, wollman@lcs.mit.edu Subject: Re: Time problems Cc: current@FreeBSD.org, wollman@FreeBSD.org Sender: owner-current@FreeBSD.org Precedence: bulk >Can we do occasional 8254 based sanity checking of the system time to >either automatically revert to the 8254 on systems that the new code >yields poor results, or simply to fix up the time occasionally? I Reverting to the 8254 early is easy. Simply don't set pentium_mhz if the error for truncating to an int would be too large. Reverting to it later and keeping the clocks in sync is harder. There is no way to tell which of the the 8254 clock and the Pentium clock has drifted without comparing them both with a external time source, and if you have such a time source then it should be possible to use it to keep the Pentium clock in sync. The 8254 maximum count and pentium_mhz should be varied to reduce adjustments. >>a bit hard to diagnose. For those machines on which the results are >>reasonable, I expect timekeeping to be rather better than it was. >>According to xntpd, my machine is within about 3 seconds per day, >>which is about the same as it was before. (It's the precision, rather >>than the accuracy, where this technique gives a benefit.) >> >>-GAWollman >Precision and overhead right? Why is it that xntpd doesn't either >complain about my large offset (I started it just after using ntpdate), >or keep my time in sync? Perhaps because of the microtime() jitter that I reported in previous mail - if the accuracy is low then the jitter becomes large when adjtime() is used to improved the accuracy. However, I guess xntpd should be able to handle large jitter. I confused precision and accuracy a bit in my previous mail. It isn't true that the Pentium clock gives more precision in the current implementation. If both clocks have _no_ drift but large inaccuracy, then the precision is proportional by the the inverse of the factor used to convert from a cycle count to a time. For the 8254 clock, the factor is 11932 and for the Pentium clock it is 90. Thus the Pentium clock is about 132 times less precise than the 8254 clock unless someone made a point of making the Pentium clock frequency an integral number of MHz. Bruce