linux-mips
[Top] [All Lists]

Re: I fixed the r4ktimer code...

To: wje@fir.esd.sgi.com
Subject: Re: I fixed the r4ktimer code...
From: "David S. Miller" <dm@neteng.engr.sgi.com>
Date: Tue, 11 Jun 1996 18:19:45 -0700
Cc: linux@cthulhu.engr.sgi.com
In-reply-to: <199606120111.SAA08986@fir.esd.sgi.com> (wje@fir.esd.sgi.com)
Sender: owner-linux@cthulhu.engr.sgi.com
   Date: Tue, 11 Jun 1996 18:11:05 -0700
   From: wje@fir.esd.sgi.com (William J. Earl)

   David S. Miller writes:
    > 
    > Calibrating delay loop.. ok - 138.04 BogoMIPS
    > 
    > Much better ;-)

        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.

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
dm@sgi.com

<Prev in Thread] Current Thread [Next in Thread>