Re: CPU frequency shifting "problems"

[Jamie Lokier <lk@tantalophile.demon.co.uk>]

Linus Torvalds wrote:
> With a CPU that does makes TSC appear constant-frequency, the fact that
> the CPU itself can go faster/slower doesn't matter - from a kernel
> perspective that's pretty much equivalent to the different speeds you get
> from cache miss behaviour etc.

On a Transmeta chip, does the TSC clock advance _exactly_ uniformly, or
is there a cumulative error due to speed changes?

I'll clarify.  I imagine that the internal clocks are driven by PLLs,
DLLs or something similar.  Unless multiple oscillators are used, this
means that speed switching is gradual, over several hundred or many more
clock cycles.

You said that Crusoe does a floating point op to scale the TSC value.
Now suppose I have a 600MHz Crusoe.  I calibrate the clock and it comes
out as 600.01MHz.

I can now use `rdtsc' to measure time in userspace, rather more
accurately than gettimeofday().  (In fact I have worked with programs
that do this, for network traffic injection.).  I can do this over a
period of minutes, expecting the clock to match "wall clock" time
reasonably accurately.

Suppose the CPU clock speed changes.  Can I be confident that
600.01*10^6 (+/- small tolerance) cycles will still be counted per
second, or is there a cumulative error due to the gradual clock speed
change and the floating-point scale factor not integrating the gradual
change precisely?

(One hardware implementation that doesn't have this problem is to run a
small counter, say 3 or 4 bits, at the nominal clock speed all the time,
and have the slower core sample that.  But it may use a little more
power, and your note about FP scaling tells me you don't do that).

thanks,
-- Jamie