Subject: I fixed the r4ktimer code...

From: "David S. Miller" <[email-masked]>
Date: Tue, 11 Jun 1996 17:04:30 -0700

Calibrating delay loop.. ok - 138.04 BogoMIPS

Much better ;-)

Later,
David S. Miller
[email-masked]

---

From: [email-masked] (William J. Earl)
Date: Tue, 11 Jun 1996 18:11:05 -0700

> Calibrating delay loop.. ok - 138.04 BogoMIPS

     Yes, except that it should really be 133.33 on the 133 MHZ R4600SC.
I don't have any idea where the 4% error would be coming from, unless there
is something wrong with the external timer.  One way of checking the timer
might be to measure a tick of the Dallas clock/calendar chip.  I believe
the one we use in Indy counts 0.01 second units, so noticing the 
$count change over, say, a 0.5 second interval, as measured by the
Dallas part, would be a way of validating the timer configuration.

---

From: "David S. Miller" <[email-masked]>
Date: Tue, 11 Jun 1996 18:19:45 -0700

Date: Tue, 11 Jun 1996 18:11:05 -0700
   From: [email-masked] (William J. Earl)

Peculiar... but I believe if you look at the calibrate_delay()
function I sent you earlier you will see that the way it performs the
calculation implies a certain error fuzz all in the name of efficiency
(some time back calibrate_delay() was much more accurate but took 3 or
4 seconds to run at boot time, ugh, the lesser of two evils)

The new way I calculate the r4k compare register offset is that I set
the rate generation of the Intel counter at 1HZ.  I then make 4
samples of how far the r4k counter goes every time the Intel counter
makes a full 1 HZ iteration.  I then average these 4 samples and
multiply by HZ (which == 100 for the Mips port of Linux) to find the
final r4k offset value that I use.

Anyways, BogoMIPS is by definition "bogus" ;-) It is only used by
the kernel to do quick microsecond delays in various places of the
kernel.

Later,
David S. Miller
[email-masked]