> For accurate performance measurements it is also important to calibrate the
> interval timer. I am thinking along the lines of using the Real Time Clock as
> a standard and then measuring the interval against the RTC. On most machines,
> the RTC drift is on the order of a few seconds per day or about a minute per
> month.
> Time drifts on this order are acceptable for determining the exact count needed
> by the interval timer on a specific machine. By using a common calibration
> algorithm we can more reliably compare performance results.
In my experience the internal timer of a PC is more accurate than the
RTC clock. If anything you would have to calibrate the RTC against the
internal timer. Also note that you cannot set the timer interval very
precicely. If you want an interval of about 10 ms, the counter has a
value of about 12000, which means that increasing or decreasing it by
1 changes the error per day by about 8 seconds. You can work around this
by maintaining the time at a very fine level (e.g. at nanoseconds) and
then determine the length of a clock interval at that resolution (so
after calibration you find that a clock interval is 10,000,538 ns, for
example).
> Also note that by calibrating the clock, we can also get a performance metric a
> la Linux's BogoMips.
How do you do that? You are just comparing one counter against another,
none of which has anything to do with CPU speed.
> By normalizing any performance measure against the
> BogoMips, we can see the true costs/benefits of VSTa and its algorithms in a
> machine independent fashion.
No, please don't use BogoMips for anything which looks even remotely
like a benchmark. What do you think the `Bogo' stands for? BogoMips
measures only a few instructions, and the measurement is intended as a
base for delay loops which use the same instructions.
hp
-- _ | Peter Holzer | hp@vmars.tuwien.ac.at | hjp@wsr.ac.at |_|_) |------------------------------------------------------ | | | There are lies, damned lies, and benchmarks. __/ | -- anon.Received on Tue Feb 14 08:12:29 1995
This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:17 PDT