Mailing List ArchiveSupport open source code!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]tlug: NE2000 cards
- To: tlug@example.com
- Subject: tlug: NE2000 cards
- From: Chris Sekiya <chris@example.com>
- Date: Wed, 31 Mar 1999 10:27:52 +0900 (JST)
- Content-Type: TEXT/PLAIN; charset=US-ASCII
- In-Reply-To: <14080.59977.599126.203202@example.com>
- Reply-To: tlug@example.com
- Sender: owner-tlug@example.com
On Wed, 31 Mar 1999, Stephen J. Turnbull wrote: > ash> You can get get rid of the '(aka "Satan spawn")' bit. > > Yes. That's code for "Chris was here." Doesn't mean anything to the > kernel. *snort* That one wasn't me -- must be someone else who shares my (dim) view of Novell Eagle workalike cards. I've said many times that ne2k cards are absolute crap, but I've never really explained why. For those who are curious: The Novell Eagle 1000/2000 card is built around the DP8390 and DP8391 ethernet chips, a bit of RAM for buffering (typically between 16 to 64Kb), and some glue parts. It is an absolute bare-bones implementation -- essentially Novell took the example configuration from the 8390 datasheet and threw it together. The 8390 is designed for DMA operation -- the RAM is used as the buffer. For transmission, the CPU writes the packet to the RAM and then tells the 8390 to transmit. Packet reception works in a similar manner. The engineers at Novell apparently decided that DMA was unnecessary, as they did not couple the buffer RAM to the system bus. So, in order to store or retrieve data to or from the RAM, the 8390 has to be used in something called remote DMA mode -- essentially programmed i/o[1], sending each byte (or word) one-at-a-time through the data port. Thereby doing nasty things to performance[2]. If that wasn't bad enough, many runs of the 8390 (and clones derived from its silicon) had a buffer bug that _required_ a dummy read from the buffer RAM for every write to the buffer RAM. The _single_ good thing about the Novell board was that it was cheap. Cheap enough to clone. They didn't perform very well (which ensured the survival of 3com), but who really cares about dropped packets with a US$150 card? Once machines became fast enough to slam the data port without generating timeouts, the Novell boards saturated the market. -- Chris [1] Some clone cards rectified this design flaw. Unfortunately, there is _no_ way to determine where in the upper 384Kb this RAM sits without opening up the box and looking at the jumper settings[3], so it is not used in the linux driver. [2] Interestingly enough, although the PCI ne2k clones can advertise their buffer RAM location via the PCI spec (neatly avoiding the need to probe), they often lie. PIO to a PCI card ... *shudder* [3] ... unless one writes a card-specific driver. Ugh. ------------------------------------------------------------------- Next Technical Meeting: April 10 (Sat), 12:30 place: Temple Univ. *** featuring: LabView and UDB/DB2 for Linux Next Nomikai: May 21 (Fri), 19:30 Tengu TokyoEkiMae 03-3275-3691 ------------------------------------------------------------------- more info: http://www.tlug.gr.jp Sponsor: Global Online Japan
- References:
- Re: Re[2]: Re[2]: Re[2]: tlug: Cable Modem Access
- From: "Stephen J. Turnbull" <turnbull@example.com>
Home | Main Index | Thread Index
- Prev by Date: tlug: differences between japanese input methods?
- Next by Date: Re: tlug: advice needed: choosing a distribution
- Prev by thread: Re: Re[2]: Re[2]: Re[2]: tlug: Cable Modem Access
- Next by thread: tlug: advice needed: choosing a distribution
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links