Re: Wrong bogomips after plugging in AC powery

Orin Eman (
Tue, 2 Nov 1999 01:12:31 -0800 (PST)

> > program will till be able to recompute the processor speed using things
> > as load average, initial CPU speed, and the time do to spin in a closed
> > loop.
> That is not going to work. It is too late by then. One single wrong
> udelay() can corrupt your data, or crash your machine [assuming broken
> hw. On good hw, no udelay is needed]. You should not run with wrong
> bogomips, not even for short periods between real change and you
> noticing it...

Agreed. It's just asking for trouble. The only time I use
software delay loops is on a processor where _I_ control the
clock speed and I have no other choice...

> What are other possible timebases? [I'm talking i386 architecture]

> timer - it has 16bit counter, and runs 18 times a second
> when 65535 is used as divider. That gives me 0.84usec precission (good
> enough). I just wonder how long it takes to do_read_hwtimer()...

It's just a few instructions at assembly level. Windows
virtual device drivers (oh the horror) have access to a
function which returns a 64 bit count of roughly 0.8 usec
intervals since boot. It's nothing more than current timer
contents + (divider * overflows since boot). Implementing
a delay wouldn't require anywhere near as much, you just need
to be a little careful if the current value plus delay wraps.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at