From owner-freebsd-current Tue May 7 16:00:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA19963 for current-outgoing; Tue, 7 May 1996 16:00:22 -0700 (PDT) Received: from mail.barrnet.net (mail.barrnet.net [131.119.246.7]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA19958 for ; Tue, 7 May 1996 16:00:20 -0700 (PDT) Received: from GndRsh.aac.dev.com ([198.145.92.241]) by mail.barrnet.net (8.7.5/MAIL-RELAY-LEN) with SMTP id QAA06593 for ; Tue, 7 May 1996 16:00:15 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id PAA02659; Tue, 7 May 1996 15:55:34 -0700 From: "Rodney W. Grimes" Message-Id: <199605072255.PAA02659@GndRsh.aac.dev.com> Subject: Re: ahc driver no longer sees one of my disks To: p.richards@elsevier.co.uk (Paul Richards) Date: Tue, 7 May 1996 15:55:34 -0700 (PDT) Cc: FreeBSD-current@freebsd.org In-Reply-To: <199605071456.PAA04953@cadair.elsevier.co.uk> from Paul Richards at "May 7, 96 03:56:41 pm" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 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