From owner-freebsd-hackers Thu Dec 18 03:24:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA10387 for hackers-outgoing; Thu, 18 Dec 1997 03:24:26 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp10.portal.net.au [202.12.71.110]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA10377 for ; Thu, 18 Dec 1997 03:24:15 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id VAA00374; Thu, 18 Dec 1997 21:48:18 +1030 (CST) Message-Id: <199712181118.VAA00374@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Andrew Gordon cc: Mike Smith , FreeBSD Hackers Subject: Re: 3com 3c509 card In-reply-to: Your message of "Thu, 18 Dec 1997 01:15:50 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Dec 1997 21:48:18 +1030 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Wed, 17 Dec 1997, Mike Smith wrote: > > > If I can't route 4 ethernet interfaces with SMC Ultras then a rigorous > > > academic exercise has no value for my purposes. I just want a rough > > > projection that's reasonably accurate. > > > > "AT Bus Design" (Edward Solari, Annabooks), p 6-101, quoted without > > permission, excerpt from table 6-3: ISA AND E-ISA PLATFORM STANDARD > > ACCESS MEMORY CYCLE LENGTH > > Note that a _standard_ cycle isn't the fastest possible cycle: 16-bit > memory cycles have one wait state, but a board can generate 0 w/s > cycles by holding NOWS* low. Since this is only applicable to memory > cycles, this is the reason the WD/SMC boards (memory mapped) used > to be considered superior to NE2000 clones (I/O cycles, hence 1 w/s min). Correct. However 0WS operation was recently enabled for the 'ed' driver and WD cards, but it had to be backed out for reliability reasons. The only other cards that I've met with 0WS jumpers have had loud warnings in the manual involving fire and the loss of your first-born. > > BUS OWNER CYCLE BEGINS CYCLE ENDS CYCLE CYCLE > > SIZE LENGTH > > --------------------------------------------------------------- > > PLAT FORM (sic) .5 TCLK TO END COMMAND 8 BITS 6 TCLK > > CPU ACT BALE ACT PERIOD 16 BITS 3 TCLK > > > > For reference, TCLK is the period of BCLK, ie. 1 TCLK ~= 120ns for the > > standard 8.33MHz BCLK. > > So a 16-bit memory cycle on the ISA bus takes at least 360ns. > > If you flip that the other way around and account for the other .5 TCLK > > idle before BALE can go active again, > > ??? You appear to be double-counting here - that 0.5 cycle before BALE > is included in the 3 cycles (or 2 cycles at 0 w/s). After all, since > the polarity of BCLK doesn't change, the interval between successive > accesses (assuming no other activity on the ISA bus) _must_ be an > integer number of cycles, so the answer can't possibly be 2.5. Hmm. My reading of the timing diagram infers that for the cycle to complete you've slopped into the 4th TCLK, ie. you can't back-to-back ISA memory cycles. (Humble admission, I've only done ISA I/O adapters, so I can't quote from any of my notes...) > > you get about 2.5 16-bit cycles > > per microsecond, or about 5MB/sec ISA memory bandwidth. > > If you can actually generate back-to-back 16-bit 0 w/s memory cycles, > you get 8Mbyte/sec. Ability to do so presumably depends substantially on > the behaviour of the ISA bridge behaviour in the chipset on modern > machines; the relationship of the ISA bus to CPU cycles is non-obvious. No joke. And if you think that's bad, try working on the other side of a PCI-to-generic bridge. 8) mike