From: "H. Peter Anvin" <hpa@zytor.com>
Newsgroups: fa.linux.kernel
Subject: Re: [RFC] CPUID usage for interaction between Hypervisors	and	Linux.
Date: Thu, 02 Oct 2008 00:45:46 UTC
Message-ID: <fa.oaBsfwINlTVfmXMP6b5lkbWu5KM@ifi.uio.no>

Zachary Amsden wrote:
>
> Jun, you work at Intel.  Can you ask for a new architecturally defined
> MSR that returns the TSC frequency?  Not a virtualization specific MSR.
> A real MSR that would exist on physical processors.  The TSC started as
> an MSR anyway.  There should be another MSR that tells the frequency.
> If it's hard to do in hardware, it can be a write-once MSR that gets
> initialized by the BIOS.  It's really a very simple solution to a very
> common problem.  Other MSRs are dedicated to bus speed and so on, this
> seems remarkably similar.
>

Ah, if it was only that simple.  Transmeta actually did this, but it's
not as useful as you think.

There are at least three crystals in modern PCs: one at 32.768 kHz (for
the RTC), one at 14.31818 MHz (PIT, PMTMR and HPET), and one at a higher
frequency (often 200 MHz.)

All the main data distribution clocks in the system are derived from the
third, which is subject to spread-spectrum modulation due to RFI
concerns.  Therefore, relying on the *nominal* frequency of this clock
is vastly incorrect; often by as much as 2%.  Spread-spectrum modulation
is supposed to vary around zero enough that the spreading averages out,
but the only way to know what the center frequency actually is is to
average.  Furthermore, this high-frequency clock is generally not
calibrated anywhere near as well as the 14 MHz clock; in good designs
the 14 MHz is actually a TCXO (temperature compensated crystal
oscillator), which is accurate to something like ±2 ppm.

	-hpa

From: "H. Peter Anvin" <hpa@zytor.com>
Newsgroups: fa.linux.kernel
Subject: Re: [RFC] CPUID usage for interaction between	Hypervisors	and	Linux.
Date: Thu, 02 Oct 2008 01:26:03 UTC
Message-ID: <fa.7mxDn3MZeErZUNyGLudU+VpMr88@ifi.uio.no>

Zachary Amsden wrote:
>
> I'm not suggesting using the nominal value.  I'm suggesting the
> measurement be done in the one and only place where there is perfect
> control of the system, the processor boot-strapping in the BIOS.
>
> Only the platform designers themselves know the speed of the oscillator
> which is modulating the clock and so only they should be calibrating the
> speed of the TSC.
>

No.  *Noone*, including the manufacturers, know the speed of the
oscillator which is modulating the clock.  What you have to do is
average over a timespan which is long enough that the SSM averages out
(a relatively small fraction of a second.)

As for trusting the BIOS on this, that's a total joke.  Firmware vendors
can't get the most basic details right.

> If this modulation really does alter the frequency by +/- 2% (seems high
> to me, but hey, I don't design motherboards), using an LFO, then
> basically all the calibration done in Linux is broken and has been for
> some time.  You can't calibrate only once, or risk being off by 2%, you
> can't calibrate repeatedly and take the fastest estimate, or you are off
> by 2%, and you can't calibrate repeatedly and take the average without
> risking SMI noise affecting the lowest clock speed measurement,
> contributing unknown error.

You have to calibrate over a sample interval long enough that the SSM
averages out.

> Hmm.  Re-reading your e-mail, I see you are saying the nominal frequency
> may be off by 2% (and I easily believe that), not necessarily that the
> frequency modulation may be 2% (which I still think is high).  Does
> anyone know what the actual bounds on spread spectrum modulation are or
> how fast the clock is modulated?

No, I'm saying the frequency modulation may be up to 2%.  Typically it
is something like [-2%,+0%].

	-hpa