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

Bruce Evans brde at optusnet.com.au
Sat Mar 26 19:49:52 UTC 2016


On Sat, 26 Mar 2016, Konstantin Belousov wrote:

> On Sat, Mar 26, 2016 at 03:17:43AM +1100, Bruce Evans wrote:
>> This uses the i8254.
> Well, this is the part which I do not like most.  It is ridiculous
> to calibrate relatively high-quality CPU oscillator with 8245 timer,
> which often fed from separate, low-quality crystal which currently
> selected by cost and exists only for legacy purposes.  At least

I haven't seen a single (hardware) system since I started measuring
this 15-20 yeas ago on which the i8524 is not fed from the same clock
as the TSC.  Normally there is a PLL that can derives hundreds of
different frequencies from the same clock.  One is fed to the i8254,
one to the ACPI timer and one to the CPU clock/TSC.

> some hypervisors start offering modes where old ISA peripherals
> are not emulated, and I suspect that hardware would start do the
> same.  Quite possible, some variants of SoCs already do this.

Bug in these hypervisors.  A slow clock like the i8254 is much easier
to emulate than a fast one.  It is impossible to emulate real time on
a non-real-time system anyway, so almost all calibration code is likely
to break in inverse proportion to its accuracy on real hardware.

> More, we do not have any hooks to recalibrate our thought about
> TSC frequency during normal runtime.  Often, system does have very
> precise measurement of the timecounter drift due to ntp/ptp.

cpu_tick_calibrate() does exactly this (if the ticker is the TSC).

My version has a precise (~1-10 usec) measurement of the timecounter drift
relative to the RTC (or vice-versa).  This is used some time after
exit from ddb to fix up the timecounter.  This depends on RTC seconds
interrupts being perfectly periodic with low (or at least measurable)
latency.  This should be used to fix up the timecounter after suspend/
resume.  An error of 1-10 usec is good enough for an ntpd server, but
the current ACPI error in resume is not good enough for an nptd client.

>> xdel() is a specialized version of i8254 DELAY()
>> with getit() inline.  It returns the initial and final values of the

It can use any readable timer, but only the i8254 is easy to use and
available on all (non-broken) x86 systems.  Just the
ifdefs/configuratation to use another timer would be very complicated.
Using the cputicker or timecounter read functions doesn't quite work
because these functions have unknown internals which might involve
unusable timing or lockimg.

Bruce


More information about the svn-src-all mailing list