From owner-freebsd-current Mon Oct 28 19:50:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA21384 for current-outgoing; Mon, 28 Oct 1996 19:50:59 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA21375 for ; Mon, 28 Oct 1996 19:50:50 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id OAA24362; Tue, 29 Oct 1996 14:46:17 +1100 Date: Tue, 29 Oct 1996 14:46:17 +1100 From: Bruce Evans Message-Id: <199610290346.OAA24362@godzilla.zeta.org.au> To: current@freebsd.org, julian@whistle.com Subject: Re: divergence of clocks Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >On our hardware here, we are seeing the clock getting out by some quite >large amounts >(xntpd is correcting by about a second every 20 minutes.) An error of 1 part in 1200 for the i8254 clock is not unusual. My boot messages say: Oct 28 23:44:52 alphplex /kernel: Calibrating clock(s) relative to \ mc146818A clock ... i586 clock: 132622333 Hz, i8254 clock: 1193100 Hz Oct 28 23:40:05 besplex /kernel: Calibrating clock(s) relative to \ mc146818A clock ... i8254 clock: 1193646 Hz Oct 25 09:27:40 gamplex /kernel: Calibrating clock(s) relative to \ mc146818A clock ... i8254 clock: 1192170 Hz The nominal i8254 frequency is 1193182. Thus the errors relative to the mc146818A clock on my machines are: RTC accuracy from other measurements alphplex: -82 / 1193182 = -68 ppm good besplex: +464 / 1193182 = +388 ppm bad gamplex: +1012 / 1193182 = +848 ppm good >the RTC however seems to have the correct time >(or something closer to it) >what are the reasons (for not) and ramifications of, using the RTC >for all getimeofday() requests? THe RTC is no good for gettimeofday() because it doesn't have any readable counters more precise than its seconds counter. >and can THAT clock be synced using xntpd as well? It could be used as a time base and synchronized with every now and then, either directly or via xntpd. This isn't implemented. It is only synchronized with xntpd if xntpd decides to step the clock. Then xntpd does a settimeofday() and the time is written to the RTC. The system time is not written to the RTC on shutdown because FreeBSD doesn't know if it is any more accurate than the time already in the RTC. The system time isn't written to the RTC on every xntpd or internal PLL update because there would be too many writes. >(I suspect that that RTC clock would not be controllable that way, Not directly, but it can be controlled by keeping some state in RAM, just like the i8254 clock. >and that it might be difficult to change the system clock to use the >RTC.. This would be easy. Implementing a good version of microtime() using the RTC is impossible. A fairly good version of microtime() can be implemented using the RTC and another counter with higher resolution (one of the i8254 counters or the i586 timestamp counter). Unfortunately, it It would have jitter from the RTC interrupt latency just like the i8254+i586 counter implementation had until I fixed it by reading the i8254 counter a few days ago. >I didi note however that the RTC is reported as producing interrupts, >so wohat would it take to set Hz to 128 and use that tick instead? 1. Set Hz to 128 and use that tick instead :-). 2. Fix any dependencies of the xntpd support on the magic number 100. 128 may be close enough to 100 for there to be no problem. 3. Replace microtime() by a version with a resolution of only 1 part in 128 :-(. Better method (only wortkks in -current): set the i8254 frequency to something closer to what it actually is using `sysctl -w machdep.i8254_freq=whatever'. Look in the boot messages for a value calibrated relative to the RTC. You can also configure to use this value automatically, but this only works right if the RTC is accurate. Accuracy is still limited to 50 ppm by rounding of the i8254 frequency and probably to more than that by temperature dependencies. Bruce