From owner-freebsd-hackers Thu Dec 18 05:06:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA16668 for hackers-outgoing; Thu, 18 Dec 1997 05:06:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA16658 for ; Thu, 18 Dec 1997 05:06:46 -0800 (PST) (envelope-from arg@arg1.demon.co.uk) Received: (from arg@localhost) by arg1.demon.co.uk (8.8.5/8.8.5) id NAA18771; Thu, 18 Dec 1997 13:05:52 GMT Date: Thu, 18 Dec 1997 13:05:51 +0000 (GMT) From: Andrew Gordon X-Sender: arg@server.arg.sj.co.uk To: Mike Smith cc: FreeBSD Hackers Subject: Re: 3com 3c509 card In-Reply-To: <199712181118.VAA00374@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 18 Dec 1997, Mike Smith wrote: > > 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. Hmm. Problem here seems to be the wide variety of cards the ed driver supports (besides the wide variety of machines people plug them into...) Some of the problems noted in the commit log against that change don't really relate to the 16-bit memory accesses at all (eg. failure to read the MAC address from the EEPROM on warm boot). > > ??? 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 can get back-to-back cycles, at least on a real ISA bus machine: there is a degree of overlap (depending which point you consider to be the 'start' of the cycle, either the high-order addresses have started to appear before the end of the previous cycle, or the data bus is still in use during the start of the next cycle). This probably does mean that you miss a cycle doing individual accesses across a PCI->ISA bridge (because you don't get the next address available), but a good bridge ought to be able to pipeline a burst of memory accesses. Mind you, I don't suppose chipset manufacturers care too much about their ISA performance these days, considering the ISA bus just to be there for legacy devices - if the customer cared about performance, they'd have bought a PCI Card, wouldn't they? Either way, this doesn't affect the advantage of 0WS over 1WS: it's just a question of whether it is 2 cycles vs 3, or 3 vs 4. Just a shame we can't use it; perhaps a flags option in the ed driver would be in order to enable 0WS for the benefit of speed-freaks with carefully chosen hardware?