cvs commit: src/sys/conf options.i386 src/sys/i386/i386 tsc.c src/sys/i386/conf NOTES

[Poul-Henning Kamp]

In message <20030407163148.L3478 at gamplex.bde.org>, Bruce Evans writes:

Sorry Bruce, but this is a fair bit more complicated than that.

It is true that the temperature coefficient of the RTC crystal and the
crystal which (usually) drives the i8254 and TSC are different, but
we are nowhere close to being able to measure that in a one second
interval with the kind of jitters we suffer in accessing the RTC.

If we did many observations or used longer integration times, we might
be able to improve it, but it is certainly not something we can even
contemplate waiting for during bootup.  Once we have booted, NTPD
beats anything we can do (see below before protesting about lack
of network connectivity).

>Another thing the old code got right was calibration of the i8254 relative
>to the TSC.  They obviously use the same hardware clock on at least
>all of my active machines (BP6, A7V266-E), since the calibrated ratio
>is always the same (as far as ntp running over a long period can tell).

This is generally true, and while the Xtal is normally the 14.318MHz[1]
neither are universal facts.

I played with detecting the actual PLL ratios, and this generally is
a viable avenue under the normal circumstances, but sufficient "odd-ball"
systems exist that I am not comfortable with it in general.

>The old calibration code calibrates them relative to another clock so
>the only error in their relative frequencies is from the different time
>that it takes to read their counters.  The i8254 counter typically takes
>5 usec longer to read, but for some reason the actual error is less than
>1 i8254 cycle on all of my active systems.

That is because the i8254 access is synchronized to the "virtual" ISA
bus frequency and your CPU is much faster than that.

The best result I have had so far, and the only one I have sufficient
faith in to advocate its use in general, takes an entirely different
route:

The RTC interrupts us at 128Hz for statclock, divide this in software
to get 1Hz and take timestamps and feed them to the NTP kernel-FLL code
and tell NTPD to lock to that at a high stratum.  

This will synchronize the clock to the RTC frequency.

It may be possible to detect the RTC second roll-over and feed absolute
timestamps to the NTP kernel-PLL code to also synchronize to the RTC
in phase.

Poul-Henning

[1] fun fact:  The 14.318MHz is four times the color burst frequency
of NTSC television signals, and was chosen by IBM for the original
IBM PC because it made it possible to generate four different colors
in a purely digital fasion on a television connected to the CGA.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.