Originally published at: https://boingboing.net/2019/06/07/why-was-a-bogomip-bogus.html
…
5 Likes
IIRC, it began to be phased out when teh 586 came out as it had the RDTSC instruction to read the timestamp counter–a clock that incremented once every instruction cycle–and that was way more accurate and easy to use. There are whole platforms that never used BogoMIPS because they had an accurate archetecture level timer at the time of porting–so they never needed NOP based busy loop.
My first Linux install was on a 386DX16. Boot and root floppies…Good times. Earliest version I used was 0.14, but it didn’t do a ton. 
2 Likes
I first recall watching the BogoMIPS number as we brought up a quad-processor PowerPC VMEbus board in the late nineties. That was back when the kernel barely knew what to do with four CPUs.
4 Likes
Some device drivers in the Linux kernel need timing delays. Either they need a very short delay, or the delay must be very accurately determined.
Years ago in a High Tech Company we had a test device that booted and loaded code from an eight inch floppy. A new developer took over the maintenance for the code and saw all of these no ops. He didn’t know what they were so he took them all out. Nothing worked after that. I never heard what happened to him.
1 Like
I’ll vote for “nothing; but he never worked again.”
After a lifetime of hearing that he should take a vacation and learn to relax, he finally snapped.
Thanks. That was entertaining.
1 Like
That’s still not going to measure operations per second, which aren’t glued to integer clock reportability (wait, is there branch-if-almost-done instruction much?) though ‘done within n’ is a binding promise when it comes to writing compilers…er, llvm modules?) and GOPS/TOPS measurements aren’t exempt from the bogo- prefix in shop^Winvestor talk.
Yeah, one has to have the fortitude to try removing -half- the NOPs. Somewhere, in some college (clade of colleges? Varietal college?), things are training to take the l337 ‘junior fault instigator’ jobs.
In that vein, while x86 didn’t at the time, have BogoMips been deprecated with the Advent of APIC or HPET, preserved for backward compatibility; or do those address different requirements and their availability isn’t relevant?
I’d imagine that, at a minimum, the fact that basically every vaguely modern x86 can adjust its clock speed all over the place pretty rapidly has made the classic BogoMips measure less broadly helpful(or substantially more complex to use; you’d need to compute it for all viable clock rates and know how much time the CPU spent in each one for the relevant period).
My technological ignorance is such that your post and Flossaluzitarin’s make about the same amount of sense to me…
I get a bit scared when one of Flossaluzitarin’s posts almost seem to make sense. I worry that one day they will make sense to me and I’ll suddenly find myself telling everyone about the coming of the King in Yellow or babbling about the things in the angles.
3 Likes
Didn’t the comments in the code explain them? 
1 Like
Yes, the ability to scale clock speed dynamically killed the TSC and busy loops as a means of delay timing. Fortunately, that is later than the advent of the HPET–which is how all precise busy wait type of timing is done in Linux these days. Your guesses were all correct.
1 Like
I know what I’m doing on this subject and Flossaluzitarin’s post made no sense to me. I think it’s just a Markov chain generating text.
@RickMycroft, If it was hard to write it should be hard to read. 
2 Likes
Honestly it would have been a lot more readily comprehensible if I’d refrained from the acronyms: the Advanced Programmable Interrupt Controller includes a timer feature; and the High Precision Event Timer is substantially what it says on the tin; and having a dedicated mechanism for measuring the passage of short periods of time makes the “allocate the CPU this much busywork because we know how fast it is at busywork” timer rather…crude…at the same time variable clocking means that you actually don’t know how quickly the CPU can complete busywork(since it can work at various speeds; and forcing it into a specific speed state just to use it as a timer is brutally inefficient).
Because platform features…don’t always perform as advertised…I wasn’t sure if Linux had been able to drop support for fallback mechanisms or whether all reasonably modern and mainstream kernels can and do trust them to work; but at least in noble principle the HPET is pretty much the specialized solve-exactly-the-problem-BogoMips-were-a-bodge-for peripheral; so one is left to suspect that it’s a likely replacement.
1 Like
Oh come on, who wouldn’t document a string of nops?
1988 is on the other line…
Drive2:
lodsw ; Fetch index to DispBuf from RamTable
mov bx,ax
mov al,[bx] ; Fetch actual data item
out dx,ax ; Load shift, then clock with 2nd byte
loop Drive2 ; Around we go...
mov al,DispCnt
or al,00010000B ; Inhibit active
mov dx,CARD_8255_C
out dx,al
nop
nop
nop
nop
nop
nop
or al,00100000B ; Strobe new row to display
out dx,al
dec al
and al,0FH
or al,00010000B ; Inhibit active
out dx,al ; New row, display off
nop
nop
and al,0FH
out dx,al ; Switch on...
mov DispCnt,al ; Have we wrapped by displaying
jnz Drive3 ; all lines on the display?
mov al,00010000B
out PPI_8255+1,al ; Switch on IOChk NMI
mov si,offset RamTable ; Yes, start at begining again
inc FrameTick ; Flag a page completed
Drive3:
Hmph, well it could happen to anyone.
2 Likes
This was before comments had been invented.
1 Like
That’s what worries me. It whispers infinite, incomprehensible wisdom from the cosmos. Then it replies directly to a post with links to mystic knowledge.
I mean, tell me this couldn’t be splashed into a modern Lovecraft pastiche as part of a text of forbidden knowledge man is not meant to know:
Professor Jenkins ignored that warning and was never seen again…
1 Like
This topic was automatically closed after 5 days. New replies are no longer allowed.
