Date: Tue, 7 May 1996 15:55:34 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: p.richards@elsevier.co.uk (Paul Richards) Cc: FreeBSD-current@freebsd.org Subject: Re: ahc driver no longer sees one of my disks Message-ID: <199605072255.PAA02659@GndRsh.aac.dev.com> In-Reply-To: <199605071456.PAA04953@cadair.elsevier.co.uk> from Paul Richards at "May 7, 96 03:56:41 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> In reply to Paul Traina who said
> >
> > The delay macro, is by definition, processor speed independant.
> > If it changes significantly, then it's broken.
> >
>
> Rod had me run some DELAY tests on one of my boxes and I remember there
> being problems. I've forgotten what we were trying and what the results
> were, maybe Rod still has the mail?
One of the biggest problems with high speed systems is that DELAY(n) for
n < 20 is _ASSUMED_ to be the call/return overhead. This is horribly
wrong for loops that call DELAY(n) reapeadly due to cashing, branch prediction
and a whole lot of other things.
See the source code in clock.c:
/*
* Read the counter first, so that the rest of the setup overhead is
* counted. Guess the initial overhead is 20 usec (on most systems it
* takes about 1.5 usec for each of the i/o's in getit(). The loop
* takes about 6 usec on a 486/33 and 13 usec on a 386/20. The
* multiplications and divisions to scale the count take a while).
*/
prev_tick = getit();
n -= 20;
/*
...
On a P133 this looks to be closer to 4uS, on a 166 it is down to 2 or 3uS,
and I have no idea what it is on a P6. This value should probably be
calibrated, perhaps bruces recent changes could be enhanced to calibrate
this as well...
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605072255.PAA02659>