Subject: Re: probing CPU speed?
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Dave Sainty <email@example.com>
Date: 11/21/1998 17:41:18
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
> (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.