Why was a BogoMip bogus?

Originally published at: https://boingboing.net/2019/06/07/why-was-a-bogomip-bogus.html


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. :slight_smile:


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.


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.


Didn’t the comments in the code explain them? :wink:

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. :wink:


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

Don’t lose that don’t-know-mind!

Oh come on, who wouldn’t document a string of nops?

1988 is on the other line…

	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
	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
	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

Hmph, well it could happen to anyone.


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.