>If clock rate could be simply probed on PC's, it would be nice to
>print.  It can't.

hi Dave,

Perhaps `simple' means something different to us NTP time-vultures?

Here (again) is more-or-less how I do it on mips, where the PROMs dont
put this info somewhere useful like they do on Alphas:

Write a loop to wait until the next RTC tick.
When the tick fires, read and save the CPU cycle counter.
Poll until the next RTC tick. 
    (it helps to set up an interrupt for the RTC, and set a flag in the 
     interupt-handler; then loop until the flag is set so you're not stuck
     doing polling to slow off-chip accesses. mips chips often have an RTC mapped direct to an interrupt line,
     which makes this trivial.)

Re-read the cycle counter when the flag is set.

Compute difference between two clock-cycle readings.
>From that and the known RTC tick rate,  and compute CPU clock-speed.

(What the mips code acutally does is count loop iterations, and from
that, interpolate cycles that works on CPUs without a cycle-counter,
but it does require calibrating the loop multiplier for effects like
dual-issue.  Perhaps it should be redone as I've described.)

CPU clocks are usually multiples of some basic clock frequency, so you
can bucketize to those discrete increments very easily.  Modern x86es
-- Pentium, Pentium Pro/Pentium II (i'm told even the IBM 486-DX4
cores) -- have a CPU-clock cycle counter, and can do the more-accurate
count-cycles-between-known-time-intervals version.

That's gets a clock-rate estmiate good enough to start using the CPU
cycle-counter for NTP purposes-- let alone good enough to fine-tune
delay() or use as a `model-number' MHz rating.

If doing the loop-count and scaling (ala bogomips, AFAIK) is not
accurate enough, just print a message saying the CPU clockrate cannot
be measured, because there's no CPU cycle-counter.

Seems simple enough to me.