Messages in this thread | | | From | Orin Eman <> | Subject | Re: Wrong bogomips after plugging in AC powery | Date | 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.
Orin.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |