Jonathan Stone writes:

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

That's "almost simple". :)

If a scheme like this worked accurately with all (non-obsolete)
x86-like CPUs, it wouldn't be too bad and would be fairly reliable I
expect.

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

That's very not simple, mucking around with known-cycle-count loops.
Impractical with so many 8086 compatibles.

Cheers,

Dave