Date: Tue, 29 Oct 1996 14:46:17 +1100 From: Bruce Evans <bde@zeta.org.au> To: current@freebsd.org, julian@whistle.com Subject: Re: divergence of clocks Message-ID: <199610290346.OAA24362@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610290346.OAA24362>