From owner-freebsd-hardware Fri Aug 23 18:26:21 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA16063 for hardware-outgoing; Fri, 23 Aug 1996 18:26:21 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA16053 for ; Fri, 23 Aug 1996 18:26:18 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id KAA24070; Sat, 24 Aug 1996 10:56:02 +0930 From: Michael Smith Message-Id: <199608240126.KAA24070@genesis.atrad.adelaide.edu.au> Subject: Re: ASUS SC200 SCSI card? To: se@zpr.uni-koeln.de (Stefan Esser) Date: Sat, 24 Aug 1996 10:56:02 +0930 (CST) Cc: hardware@freebsd.org In-Reply-To: <199608232024.WAA22814@x14.mi.uni-koeln.de> from "Stefan Esser" at Aug 23, 96 10:24:26 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Stefan Esser stands accused of saying: > > Michael Smith writes: > > Rodney W. Grimes stands accused of saying: > > > > > 2. PCI latency was set to 80... Michael Smith suggested it be lower than > > > > 32 to i've moved it to 20. > > > > > > Set it to exactly 32, no more, no less. ASUS and others have done > > > 100's of hours of testing and this was found to be the best setting. > > > > Even with two 810's coming up for an opcode every us? I'd have > > thought you'd want to allow for (max latency + one opcode fetch) < 1us > > so that the second one didn't starve... > > This isn't how the latency timer works ... > > The latency timer prevents a device with > a large internal buffer from sending long > bursts, which else might cause overruns > in receive buffers of other devices. ... but this is (as far as I can tell) exactly what I was saying; the latency timer defines how long another device can hog the bus. If the 810 wants the bus every us (it may not, I'm just using this as an example), then the latency must be set to 1us or less so that a device that starts a burst just before the 810 requests the bus will stop before the 810 starves. If you add another 810, and assume that it comes up for a fetch just after the first 810, which is held off by a burst from a device that runs the full time allowed (128 bytes, not too long). Then the first 810 gets the bus and fills its pipeline; has more than 1us expired? is the second 810 starved? Does it actually care? These are the questions that would lead me to suggest backing the latency timer down. Practical experience (offered by RG and co.) suggest that I'm wrong, but I guess I just don't understand why 8) > Regards, STefan Thanks for taking the time to explain... -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[