Very Computer

I've read the mini-howto on bogomips.

The basic question is "what is the calculation method?"  And  more
specifically "how can it fail?"  

Plus "is it reasonable to change loops_per_sec in the kernel to match
what the bogomips should be in the calculation seems flawed?"

The problem is on a KeyData Notebook.  486DX 4/100, Chipset is Pine
from PicoPower.  Phoenix BIOS A486 v 1.03 for PicoPower PT86C 368/388
MB5 V1.10 (the latter related to a custom design for the notebook
manuf).

A Cyclades card is plugged into the docking station.  The Cyclades
card generally doesn't work.  It will work in another computer.

Upon talking to Cyclades & KeyData, we found that the Bogomips were
being reported at 6.55 when they should be something like 50.08.

The Cyclades driver (and perhaps other drivers) relies on the Bogomips
calculation being a bit more accurate.

When KeyData tried a 486DX/33, the Cyclades worked 7 of 7 times.  The
Bogomips report from that chip was 5.8 and should have been about 16.
So, that supports Cyclades theory that the problem is a bad bogomips
calculation.

I'm going to try a quick & dirty fix of just multiplying the delays in
cyclades.c by 7 or 8.  That's the "hack" fix.  However, I'd like to
take a stab at the general problem.

But all I have is odd-ball ideas.  Could the caching be off during the
calculation and then magically turn itself on?  If that was true, I
could (safely?) hard-code the loops_per_sec in the kernel?

I've yet to find the source yet for the calculation (anyone know which
file?).

And does anyone have any ideas?  Odd ball or not...

(snip)

I now know more thanks to Jeff Tranter's stand alone Bogomips program.

The computer is question reports a bogomips value of 6.55 when booting
and 49.71 when multiuser.

Of course, if anyone knows why this is, I'd love to hear about it
(mostly curious).

However, my question is - "Is it wise to change the loops_per_sec
variable in the kernel to match the 'correct' bogomips value for that
computer?"
Hugh