svn commit: r297039 - head/sys/x86/x86

[Konstantin Belousov]

On Mon, Mar 28, 2016 at 04:22:59AM +1100, Bruce Evans wrote:
> On Sun, 27 Mar 2016, Konstantin Belousov wrote:
> > We could even trust CPU report about its frequency as the last resort.
> > From what I saw, the calibrated RTC frequency is very close to the
Err, that should have been TSC, and not RTC.

> > reported frequency, and if runtime recalibration based on ntp client
> > feedback is implemented, all would be good.
> 
> phk axed my RTC calibration code (actually i8254 and TSC calibration code
> starting from the RTC).  It worked perfectly except it didn't adjust for
> the time to read the hardware.  The problem with it is that the RTC is no
> more or less accurate than the other timers.  It should be, but isn't in
> practice.  Normally it it is controlled by different hardware (crystal?)
> with different temperature characteristics and different exposure to
> temperature changes by being physically separate.  The i8254 is supposed
> to run at precisely 1193182 Hz but usually has an inaccuracy of 10-50 Hz.
> The RTC seconds update is supposed to occur at precisely 1 Hz but usually
> has an unrelated inaccuracy of similar magnitude.  Calibrating these clocks
> relative to each other just gives the relative difference in their
> inaccuracy.  The difference can be measured very accurately at any time.
> It varies later with temperature.  I never finished code to track the
> termperature changes and calibrate adjustments based on the temperature.
> It is simpler to start with a hard-coded i8254 frequency of 1193182 and
> adjust everything later.  ntpd handles adjustment of a single timer well
> enough.  This works because the nominal frequency of 1193182 is so standard
> that inaccuracies in it are closer to 10 ppm than the 1000 ppm that would
> break ntpd.
> 
> Bruce