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>