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

[Poul-Henning Kamp]

--------
In message <20160328033624.N850 at besplex.bde.org>, Bruce Evans writes:

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

Which means the PLL probably was 49:3 from the 14.31818 MHz xtal to
233.8636 MHz CPU frequncy.

>Newer systems have much higher resolution so the ratios are rarely integers.

PLL's in EMI-spec'ed environments are never unity ratio because that
would needlessly add to the EMI trouble.

>It should be, but isn't in practice.

The RTC was only expected to be better than the other timers,
in the very long run - weeks to years.  In particular, most of
the RTC xtals run 20-40K hotter than their turn-over point ~23C,
so they keep awful time while the system is running.

(The 32.768kHz xtals are designed for wristwatches where you
body-temperature keeps them at stable temperature.  Don't take
your wrist-watch off at night if you want it to precise.)

>The i8254 is supposed
>to run at precisely 1193182 Hz but usually has an inaccuracy of 10-50 Hz.

50PPM is a very common crystal spec, that would be +/- 60Hz.

(merging emails here)

>> A very important and relevant detail here is that the *only*
>> clock/counter which has a standardized frequency *is* the i8254
>> counter.
>
>Not even the ACPI timer?

Not that I'm aware of.  In most cases it runs at 14.31818 MHz, but
I've seen it as low as 1MHz and as high as 25 MHz.

>> The RTC *crystal* may not even exist, [...]
>
>It can give a precision of 1/32K seconds fairly easily (but with lots of
>overhead) by interrupting at 32 KHz.  1KHz is sometimes used for profiling.

Only if the 32.768 kHz RTC xtal exists.  These days silicon oscillators
are gaining ground in that segment.

> Jitter is what I'm most worried about for virtual systems.
> Jitter is quite good for a hardware RTC. [...]
> Its hardware jitter is insignificant compared with the jitter
> from interrupt latency.

If interrupts are involved their latency+jitter will overshadow
any other noise source, if nothing else because of the quantization
to clock/bus frequencies.

Jitter on the raw xtal is in picoseconds if not femtoseconds, as
it needs to be when you PLL it up to GHz.

>> Usually the errors will be magnificient, so a trivial sanity-check will
>> catch them.  Don't leave home without it.
>
>But then you have the problem of handling them.  There might be just 1
>timecounter source that is emulated correctly, but you don't know which
>it is.  There might be none.

Indeed:  One clock or three, never two.

John R. Vig's famous tutorial is the ultimate collection of wisdom
about care and feeding of quartz:

	http://www.ieee-uffc.org/frequency-control/learning-vig-tut.asp

Highly recommended.


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