Date: Wed, 28 Aug 1996 10:02:38 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: se@zpr.uni-koeln.de (Stefan Esser) Cc: msmith@atrad.adelaide.edu.au, se@zpr.uni-koeln.de, hardware@freebsd.org Subject: PCI latency? (was Re: ASUS SC200 SCSI card? Message-ID: <199608280032.KAA09127@genesis.atrad.adelaide.edu.au> In-Reply-To: <199608271825.UAA04079@x14.mi.uni-koeln.de> from "Stefan Esser" at Aug 27, 96 08:25:45 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Stefan Esser stands accused of saying: > > Well, you most probably are right. That was what you were saying. > > But having the Latency Timer set to guarantee the NCR's instruction > fetches at a rate of a few million a second (it takes 12 clocks to > execute an instruction, which is equivalent to a cycle time of 360ns) > seemed so strange an idea, that I didn't think you really meant that :-) Uh, is that a cycle being 12 clocks/360ns? Then you _do_ want the 810 fetching about 3 million instructions a second, assuming it runs non-stop, however ... > ... then the longer latency that results from the NCR not > being able to fetch the next instruction immediately when its done > with the previous one. The instruction fetches occur when the NCR is And this answers the really critical question I had, which was whether the '810 barfs if it can't fetch when it wants to. From the sound of this it doesn't, so the issue isn't one of keeping the part alive, but keeping it happy. It all becomes clear 8) > Regards, STefan -- ]] 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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608280032.KAA09127>