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

[Konstantin Belousov]

On Sun, Mar 27, 2016 at 06:49:40AM +1100, Bruce Evans wrote:
> 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.
Hm, I was able to track this down in the public documents.  I was wrong,
but your description is not completely correct either.  Please see
http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/x99-chipset-pch-datasheet.pdf
page 64 for the diagram of the clock signals interconnect on Romley and
later. Also the CK420BQ (clock synthesizer) and DB1200Z (clock buffer
for PCIe and CPU) datasheets are available on the idt.com site, but
there I can only understand the claims about jitter.

>From the diagram at the page 64, main clock is fed into CPU PLL (directly
driving TSC and LAPIC timer) and into PCH (south bridge, where all other
counters reside).  In PCH, misc. PLLs are used to drive all counters except
RTC.  RTC needs its own dedicated crystal.

I was not able to find any specifications for allowed jitter in PCH PLLs,
but I would expect that above IDT chips have much better stability than
something in overheating PCH.

> 
> > 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.
RTC does not require any emulation at all, only some adjustments which
are already facilitated by the virtualization 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.
I think we have no choice but do something for ISA/LPC-less configurations.
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
reported frequency, and if runtime recalibration based on ntp client
feedback is implemented, all would be good.