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

[Bruce Evans]

On Sun, 27 Mar 2016, Konstantin Belousov wrote:

> 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.

Of course the details are machine-dependent.  My oldest system on which I
discovered PLL-like behaviour was from late 1997.  The PLL might not have
been in standard bus chips then.  It had a K5 (?) running at 233 MHz.
The ratio of the TSC to the i8254 was precisely 196.  This was very easy
to measure or to guess without measurement and then verify by measurements
since it is an integer.  This integer is just the one that gives the best
approximation to the nominal TSC frequency of 233 MHz starting with the
nominal i8254 frequency of 1193182.  Newer systems have much higher
resolution so the ratios are rarely integers.

>> 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.

If the RTC is in direct hardware and the timecounters are partly in
software, then it would be hard to preserve order and minimize (virtual)
jitter in measurements comparing the timers.  The timecounters would
robably need additinal complications to keep them in step with the RTC.
This care would usually be wasted since the RTC is rarely used like
that.  It would probably be easier to virtualise the RTC to keep it in
step with the timecounters.

>>>> 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.

Indeed.

> 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.

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