No, it was my go-to for years when I worked in systems sales/deployments - affordable (by contemporary standards), predictable, reliable. I went through some Linux struggles with it, but that was true of all hardware at the time. It was a lot less painful than trying to get X-Windows running on higher resolution VGA modes.
Oh, I remember fixing sources for it in Linux kernel right after 2.0.0 release to make one of the clones working. Then it was fixed properly in next release (2.0.1, or something like).
But yes, it was widespread, especially in my circles - universities, etc. in ex-ussr
Right? I'd never heard it had a bad name but I never used Linux in the 90s. I'd installed thousands of those cards through my years, they were tanks. Cheap, reliable, compatitble with everything.
I used them on FreeBSD boxes and never had issues beyond standard ISA resource sharing headaches. I didn't even know they had a bad reputation. I used to prefer the ones with jumpers to set the resources because I never trusted Plug-n-Pray on ISA.
This is a well researched and very interesting article! I especially like that it considers both the hardware and software side of things and that it includes an analysis of the Linux NE2000 driver code, its initial deficiencies and its evolution over more than 20 years.
The fix is about 20 years too late at this point. I'm kind of surprised the driver is still in the kernel. There has to be a vanishingly small number of these cards still in use in the wild. Likely the only reason it survives is there were PCI implementations.
It probably still exists to help with testing out platforms like QEMU, which need to maintain the virtual devices for even older systems which might not be free to test with.
Why should NE2000 have been bad? It was the gold standard for ISA NICs in terms of compat, with many clones available, similar to what SoundBlaster was for audio cards.
That is half the problem: there were a lot of clones, and not all were good. I never used it myself, but the stories were enough to get me to buy a bunch of 3com cards off eBay back in the day just to get something that would work.
Yes, I wish it was still like that, with those de facto standards (NE2000, SB / SB Pro2, and we could add VGA/Vesa) that HW manufacturers cared to clone or later emulate. That's what I call the golden age of the DOS days (late DOS / early Windows era). Nowadays good luck trying to run a DOS program on a current computer, as chips do not emulate each other any more and you have to have the right driver for the right chip (as if as an end-user we cared which exact property and advanced feature each NIC has, we'd just be happy if there was a standard 100 or even emulated & degraded 10 Mbps mode in such situations). Same PITA for all alternative/niche OS, which can only support a couple of NICs and sound chips (the NICs' situation is often worse because often no documentation is freely available); the only remaining thing is on graphic cards, which support a few Vesa modes (but the standard never got updated to better resolutions, and by better resolutions I don't mean 4K but much less).
As almost everyone in the comments, I had many NE2000 clone cards (they were really inexpensive, I had more cards than computers), and I never had a problem with them, and I never heard that they had a bad rep (not even with Linux).
On ISA-bus DMA: it was horrendously slow. They kept the 8237 DMA controller speed pretty much unchanged even after faster processor speeds appeared (maybe for backwards compatibility- the one thing that the PC centralized DMA controller must work for is the floppy controller).
I designed a card that used DMA before I understood this. PIO was much faster. So for example "UDMA" for the ATA-3 IDE drives was dependent on PCI-bus or on-motherboard ports.
The 8237 is an ISA device and operates at the bus speed (with some overhead, ymmv, yada yada). The bus didn't get faster so the devices it automated didn't get faster.
But PC DMA certainly did get faster. The PCI bus has bus mastering DMA (i.e. none of that fly-by nonsense implemented by the 8237) as a core feature, and PCI network cards used it. But they were expensive for quite a few years, so we were still buying ISA cards well into the 90's. Which were slow. Because ISA.
> The 8237 is an ISA device and operates at the bus speed (with some overhead, ymmv, yada yada).
It's even worse than that -- the 8237 DMA controller is clocked at 4.77Mhz for backwards compatability. The normal ISA bus clock is ~8.25Mhz. So ISA DMA is actually half the speed of ISA memory or PIO access.
That's correct, but sort of missing context. The original PC bus was synchronous, and everything lived on it. So the idea was you'd fetch an instruction byte from the bus, then another, then another, then spend a cycle interpreting the instruction, then execute the load or whatever it was on the bus, then go back to do it over again. In that world a DMA controller that can do a transfer ever other cycle is much faster than the CPU copy it would be replacing.
Modern readers, weened on PCI, see something like "The ISA bus is 16 bits wide at 8 MHz" and think they should be able to stream 16MB/s "across" it "into" main memory. But that's not how it worked with ISA. It's not how it ever worked with ISA. The memory was on the same bus! And the CPU didn't even have a L1 cache!
Indeed. Running the DMA at 4.77Mhz made a lot of sense in the context of the original PC and XT, especially since the 8237 was only rated for 5Mhz anyways...
[Not to mention that the 8088 took 4 cycles to read a byte from memory and 5 cycles to read a byte from I/O.]
The true power of the 8237 was that it never touched the data byte itself: it just manipulated the bus lines, transferring a byte directly from I/O device to memory in just 4 cycles, much faster than the 8088 could ever manage.
Yeah, I saw DMA going much slower than PIO on the ISA bus. I remember scope shots showing the strobes being longer than anything else happening on the bus.
Right, PCI bus master DMA was fast (probably true of EISA and MCA also.. but don't know first hand).
I've used lots of network cards from the BNC flavoured ones for IPX/SPX and later UTP ones for Ethernet. Most of them worked fine, and most of the time they didn't was because of drivers being not so great, or being misconfigured. Don't have any complaints about the NE2000. It was probably difficult because it was early. Later cards/drivers benefitted from things generally getting sorted out.
A few of the (much later) cheapest bargain-basement (but also popular) cards did have small buffers and had low throughput, or simply lost packets without detecting the errors.
No, it was great, but BNC / Coax ethernet was awful and horrible and an absolute nightmare to debug. I probably still have a drawer full of terminators somewhere
Yes. Good ones will have a time-domain reflectometer (TDR) that will tell you were the break or sharp bend in the cable is in addition to the standard is this cable terminated correctly test.
They will also be able to do basic connectivity tests to make sure things above the physical layer (eg: is there DHCP?) are operating correctly so you don't also need to swap to a laptop to fully troubleshoot a network drop.
Yeah, but as called out in the article, ISA (8257 style) DMA wasn't a good option either. And carving out address space came with its own set of problems, especially if you needed this to work on DOS (with maybe Windows on top)--which was pretty much the default at the time.
PCI made most of that go away with its introduction, hence me wondering what the replacement card was.
Probably something with a rtl8129/39/69 chip. I had a few dozens of those NICs in the late 90s and early 2000s university computer labs I worked at. They’re so common that they’re (almost) a standard in x86 emulation (see qemu, VirtualBox, etc.).
they still had linux kernel bugs, I remember having to port a freebsd fix to linux to get it to work in a cloud/farm application where collisions could make ALL the cards on every devices go out to lunch for 10 minutes
Ahh the good old days, I remember running a utility on Linux to set the IRQ priority of my serial port to highest to stop dropped packets when the HD or network card were busy.
Out of curiosity, did you maybe switch to a PCI card? DMA was just a better option in general with PCI than ISA, so just switching to a PCI card could likely relieve your CPU of work (unless the PCI card/driver weren't completely crap).
Note that PIO hard drive modes that were unintentionally common back then would also lead to this. You used to have to go out of your way and meddle with specific drivers to avoid PIO mode.
You could have even ended up with a double whammy if not careful. Your hard drive and network might both have relied on the CPU for data transfer in which case the system would really have ground to a halt.
I deployed probably thousands of NE2000 cards in the early 90s. They were reliable and as the article points out presented much less potential resource conflicts than competing cards. 3COM cards were particularly awful in that regard.
I have a few NE2000 clones running in retro systems I have from that era. I have an actual Novell NE1000 with a 10BASE-T transceiver connected to the AUI port running in an 1984 Zenith Z-160 luggable.
I remember the 3Com cards struggling a lot with Ethernet autodetection. It wasn't terribly uncommon to get a complaint about a slow network and find that the 3Com plugged into a hub had decided to go full duplex.
That said I was generally happy with the 3c509s, once I manually wired down the duplex setting at least.
Oh, I remember having to look at the revision code for the 3c509... If memory serves, if it wasn't one of the red ones it had to be returned, and the red were a mixed bag!
Wasn’t the 3c509 the cheap one that offloaded processing to the cpu?
One of my first professional IT gigs was helping with a big rollout of HP desktops. We had a lot of problems because of these cards and bay network hub/switches that were mutually incompatible for auto detect.
The other fun part of that gig was the VAR upgraded memory on devices, and that generation of HP was very finicky about certain memory specs.
Bah. a pair of 3c509's would do a link of 750m or so on coax. And when i needed that they were available cheap used and in bulk, which was good. Every lightning storm would fry one end of the link if not both.
I remember paying for a couple of NE2k cards in the mid 90s, as the house I was living in used 10baseT networking for our student computers.
I paid something like £15 to buy each card, and they were found in a cardboard box of "misc. networking cards". Random piles of undocumented, unlabelled cards. Most were NE2K, though there were some 3Com cards - I remember I bought one by mistake, couldn't get it working properly under Linux at the time and took it back to swap it over.
That was around the time winmodems were a thing, and my personal PC had one. My memory is that of the three/four PCs in the house only one of them had a modem that worked under Linux and so we'd use that as the common "internet" machine, setting up routing so we could get internet access via that one for 30-60 minutes a day or so.
I think the lesson here is not to believe some myth just because a nerd from the 90s wrote it down. Some guy said that the NE2k was never meant to be mass-produced and people have been repeating that for 30 years.
Back in the 1990s, I was a FreeBSD guy, and at some point I looked over the code for a few of the popular Linux ISA networking drivers for some reason and was shocked at the low quality. The code quality of the core Linux kernel is generally excellent - the code quality of these drivers was at the level of "lowest passing undergraduate's second C program". I'd not be at all surprised if this turned out bugs giving bad performance; drivers are often considered finished when they produce the expected result, and network protocols have enough recovery mechanisms that you can get the expected result with a fair number of bugs.
The NE2000 clones worked fairly well in FreeBSD at the same time all the complaints were coming over in Linux-land. To be fair: You'd usually have less support for hardware in FreeBSD than Linux at the time (and almost certainly still.)
It also didn't help that these cards often had weird hardware failures (maybe because clone?) that would make them flaky but people would keep them in service because Ethernet cards were still relatively expensive at the time and, as you point out, network protocols are pretty resilient.
I used to have to literally break flaky cards in half--not kidding. Three different people fished a card out of my trash and only stopped when they realized I physically broke it--and this was about 2001-ish.
I used to use PCI NE2000 clone cards in Windows 95. I never had any real issues using them. I do remember thinking that "who made these cards? I couldn't find the brand?!"
One thing I really hated was Windows 95's built in generic NE2000 drivers never work, and you could never find the correct driver floppy disk because you don't know the brand.
Back in the NE2000 era, I had more problems with thin-net cabling than I did with the cards themselves. It definitely didn't help that the boss had a ton of old 3270 cable lying around and insisted that it was fine for the application. Hello, impedance mismatch.
Seeing the mention of the 3C501 made me dig up old Linux source to find the amusing comments in "drivers/net/3c501.c":
Do not purchase this card, even as a joke. It's performance is horrible, and it breaks in many ways.
...
The driver is less efficient than it could be. It switches through receive mode even if more transmits are queued. If this worries you buy a real ethernet card.
...
The driver still allows only the default address for cards when loaded as a module, but that's really less braindead than anyone using a 3c501 board. :)
Wow this is from a different era. I haven’t heard developers speak that candidly or passionately since my coworkers and I had to deal with writing CSS for IE6.
Back in the 90's I had a Linux kernel panic with the message "fucking Sun blows me," with no further explanation. As in, this was actually printed to the console.
It also means they had no version control, therefore no fear of being caught. Probably programmed in Windows folders ;) Nowadays each dev will find your name for 10 years.
By the way, does the GDPR require blanking the names of ex-employees in the Git history???
> does the GDPR require blanking the names of ex-employees in the Git history
I very much doubt the GDPR overrides the irrevocable license to redistribute (GPL in this case) that each developer is granting through the act of publishing their code. My understanding is that it regulates all the unpublished, ostensibly private information that the companies you do business with collect about you.
Put another way, wouldn't it be a bit ridiculous if the author of a book demanded that their name be removed from the work years after publishing it? What are libraries supposed to do, dig out all their copies and scribble over the name?
It's a transformer - I'm guessing it's the magnetics for the 10base2 port.
You can see the two pairs of enamel wires coming out on each side the sides. There are two windings, both wound on a core spool with its axis perpendicular to the board.
What you're seeing looking like the lens of a camera is a hole in the middle of the spool, presumably used during manufacture to hold it while winding.
With a look at the data sheet [1], it seems to be a transformer used for signal and power isolation:
> The CTI provides all the MAU (transceiver) functions except for signal and power isolation. Signal isolation can easily be provided by a set of three pulse transformers that come in a single Dual-in-Line package. These are available from transformer vendors such as Pulse Engineering (PE64103) and Valor (LTll0l). However, for the power isolation a DC to DC converter is required.
The data sheet provides several sample implementations using a PE64018, PE64103, PICO 33223, or PICO 33143 for this.
Circa the late 1990s, there used to be not just this shade in the source, but a message that would be printed in the logs if a 3c501 were used. It read something like:
A choice quote from the 1.1.0 source:
"%s: 3c501 EtherLink at %#x, using %sIRQ %d, melting ethernet.\n"
which is the most deprecating thing I can see the 3c501 driver code printing, in quickly skimming through old versions of the right age (it seems to have been mostly unchanged for large swathes of time).
(I went skimming for this message out of morbid curiosity, and couldn't find it. But I did only specifically look in the 3c501 source, so maybe it was a closely related card doing it, or a not-in-kernel version of the driver?)
AFAIU 3com turned it around later, with their 100base-t card (3c95x??) generally being well regarded.
Back as a student when I moved into the dorms which had 100base-T, I did some googling (or maybe it was altavista'ing in those days, I can't remember) and it seemed the best regarded 100base-t cards for Linux were the Intel one and the 3com one. The 3com one was slightly cheaper at the local computer shop, so I got one of those.
(Somewhat later on there was a flood of very cheap DEC Tulip clones, and I got one of those too. Was happy with that one as well.)
The heady days of the late 90's, when the 3C595 (code name "vortex"), 3C905 (with "Parallel Tasking"!), and the Intel 82557/82558-based NICs (like the PRO/100B with its distinctive odd circuit board shape[1]) reigned supreme! Those were fun times.
I put out a number of Red Hat 6.2-based servers w/ the Intel NICs, got hit with the dreaded eepro100 "receiver lock-up" bug, and had to end up putting in 3C905 NICs in their place to get stable network connectivity. Good times. >smile<
At my first job there was a box of about 50 expensive 3com network cards which seemed odd, I asked what the deal was and they were faulty and the firm had been sent a bunch of replacements.
I did some testing on them and it turned out they sent an interrupt signal on every IRQ regardless of what IRQ you configured in the setup utility which caused windows to lock up.
I took them home and drilled through the traces to the unwanted IRQs on the ISA slot and gifted them out at lan parties.
Most of my experience with NE2000 drivers is as a device of last resort in QEMU. The Wikibooks article has a way better table than the project manual pages.
I remember reading a mailing list posting from a WD engineer despairing of ever persuading David Miller to operate the hardware according to specifications.
As I recall, he talked about a state machine triggered that needed a ... memory? I/O? ... read that would get as many wait states (ahhh, wait states! kids these days...) as needed to guarantee it was done. But the Linux driver would not do the read because, he said, it always returned the same value anyway. As it would, if you did.
>"The WD8003E used strictly shared memory to move data to and from the card. The entire 8K SRAM was mapped in the host’s address space, and additionally required 32 bytes of I/O port space and an IRQ. The EtherCard Plus list price was initially $399.
In contrast, the NE1000
did not map its onboard SRAM into the host’s address space
, but likewise
removed the DMA support,
and only supported PIO transfers that utilized the DP8390’s Remote DMA feature. That meant the NE1000 only required 32 bytes of I/O port space and an IRQ; no other resources were needed. The NE1000 was priced at $495 at introduction (3Com’s EtherLink 3C501 cost $595 at the time) but almost immediately dropped to $395 (just below the WD8003).
The comparison between the WD8003 and NE1000 is interesting. WD opted to use shared RAM which is faster but significantly more problematic to configure, and that was especially the case with the coming wave of 386 memory managers. Novell went in the opposite direction, choosing somewhat slower PIO but completely avoiding any configuration issues with shared memory.
Both Novell and WD decided to
drop DMA support,
probably because it avoided yet another source of configuration conflicts and because especially on PC/AT class systems, DMA was slower than either PIO or memory anyway.
It is important to keep in mind that the existing competition for the WD8003E and NE1000 weren’t fancy adapters like the 3Com 3C505 EtherLink Plus or the Exos 205T but, first and foremost, the cheapest Ethernet option available, the 3Com 3C501 EtherLink. And both the NE1000 and the WD8003E beat the 3C501 hands down, because they had a much bigger packet buffer (8K vs. 2K) and did not have the awful 3C501 limitation of having to switch between mutually exclusive transmit, receive, and host access modes.
In 1988, the NE2000 appeared. It was essentially a 16-bit version of the NE1000 with support for 16-bit AT bus (but still capable of working in 8-bit slots) and two SRAMs in an 8Kx16 configuration. This doubled the onboard memory capacity and enabled both the DP8390’s internal bus and the NE2000’s external ISA bus connection to use 16-bit transfers, significantly improving the speed at which the host could communicate with the adapter.
Western Digital released a similarly upgraded WD8013E (EtherCard Plus 16) with a 16-bit ISA interface and 16KB of onboard RAM.
On the part of Novell, the motivation was clearly not to make money on hardware but sell more software. In 1991, Novell let Anthem/Eagle take over the network card manufacturing and distribution; after all, the hardware business was something Novell wanted to get out of, not into. The main purpose of the NE1000 and NE2000 was to drive the prices of networking hardware down, and it did just that."
73 comments
[ 3.3 ms ] story [ 171 ms ] threadBut yes, it was widespread, especially in my circles - universities, etc. in ex-ussr
That is true for all articles on that site. If you were alive in the 90ies, then this site has something for you.
I spent hours and hours reading through most of it
As almost everyone in the comments, I had many NE2000 clone cards (they were really inexpensive, I had more cards than computers), and I never had a problem with them, and I never heard that they had a bad rep (not even with Linux).
I designed a card that used DMA before I understood this. PIO was much faster. So for example "UDMA" for the ATA-3 IDE drives was dependent on PCI-bus or on-motherboard ports.
But PC DMA certainly did get faster. The PCI bus has bus mastering DMA (i.e. none of that fly-by nonsense implemented by the 8237) as a core feature, and PCI network cards used it. But they were expensive for quite a few years, so we were still buying ISA cards well into the 90's. Which were slow. Because ISA.
It's even worse than that -- the 8237 DMA controller is clocked at 4.77Mhz for backwards compatability. The normal ISA bus clock is ~8.25Mhz. So ISA DMA is actually half the speed of ISA memory or PIO access.
https://wiki.osdev.org/ISA_DMA is a good reference to the ugly gory details of DMA...
Modern readers, weened on PCI, see something like "The ISA bus is 16 bits wide at 8 MHz" and think they should be able to stream 16MB/s "across" it "into" main memory. But that's not how it worked with ISA. It's not how it ever worked with ISA. The memory was on the same bus! And the CPU didn't even have a L1 cache!
[Not to mention that the 8088 took 4 cycles to read a byte from memory and 5 cycles to read a byte from I/O.]
The true power of the 8237 was that it never touched the data byte itself: it just manipulated the bus lines, transferring a byte directly from I/O device to memory in just 4 cycles, much faster than the 8088 could ever manage.
(The page also talks about breaking up DMA transfers, so a Soundblaster on the same bus can do its own DMA often enough)
Right, PCI bus master DMA was fast (probably true of EISA and MCA also.. but don't know first hand).
A few of the (much later) cheapest bargain-basement (but also popular) cards did have small buffers and had low throughput, or simply lost packets without detecting the errors.
* NE1000: £148
* NE2000: £348
Are those still in wide use today, for maybe other reasons?
They will also be able to do basic connectivity tests to make sure things above the physical layer (eg: is there DHCP?) are operating correctly so you don't also need to swap to a laptop to fully troubleshoot a network drop.
Was it the hw, or the driver? Shrug, I don't know. But the experience sucked.
Shared memory or bus master cards are easier on the CPU. Some compute and pass checksums too, which offloads more cpu.
PCI made most of that go away with its introduction, hence me wondering what the replacement card was.
I could be completely wrong, though. But yes we knew then that ISA was crap, relatively speaking. :-)
You could have even ended up with a double whammy if not careful. Your hard drive and network might both have relied on the CPU for data transfer in which case the system would really have ground to a halt.
I have a few NE2000 clones running in retro systems I have from that era. I have an actual Novell NE1000 with a 10BASE-T transceiver connected to the AUI port running in an 1984 Zenith Z-160 luggable.
That said I was generally happy with the 3c509s, once I manually wired down the duplex setting at least.
One of my first professional IT gigs was helping with a big rollout of HP desktops. We had a lot of problems because of these cards and bay network hub/switches that were mutually incompatible for auto detect.
The other fun part of that gig was the VAR upgraded memory on devices, and that generation of HP was very finicky about certain memory specs.
Good times in retrospect!
I paid something like £15 to buy each card, and they were found in a cardboard box of "misc. networking cards". Random piles of undocumented, unlabelled cards. Most were NE2K, though there were some 3Com cards - I remember I bought one by mistake, couldn't get it working properly under Linux at the time and took it back to swap it over.
That was around the time winmodems were a thing, and my personal PC had one. My memory is that of the three/four PCs in the house only one of them had a modem that worked under Linux and so we'd use that as the common "internet" machine, setting up routing so we could get internet access via that one for 30-60 minutes a day or so.
I also learned something, I thought it was an ne2000 driver as in "any 2000" as in "it works with all these generic network cards."
The NE2000 clones worked fairly well in FreeBSD at the same time all the complaints were coming over in Linux-land. To be fair: You'd usually have less support for hardware in FreeBSD than Linux at the time (and almost certainly still.)
I used to have to literally break flaky cards in half--not kidding. Three different people fished a card out of my trash and only stopped when they realized I physically broke it--and this was about 2001-ish.
One thing I really hated was Windows 95's built in generic NE2000 drivers never work, and you could never find the correct driver floppy disk because you don't know the brand.
I really don't miss thin-net.
Do not purchase this card, even as a joke. It's performance is horrible, and it breaks in many ways.
...
The driver is less efficient than it could be. It switches through receive mode even if more transmits are queued. If this worries you buy a real ethernet card.
...
The driver still allows only the default address for cards when loaded as a module, but that's really less braindead than anyone using a 3c501 board. :)
By the way, does the GDPR require blanking the names of ex-employees in the Git history???
I very much doubt the GDPR overrides the irrevocable license to redistribute (GPL in this case) that each developer is granting through the act of publishing their code. My understanding is that it regulates all the unpublished, ostensibly private information that the companies you do business with collect about you.
Put another way, wouldn't it be a bit ridiculous if the author of a book demanded that their name be removed from the work years after publishing it? What are libraries supposed to do, dig out all their copies and scribble over the name?
https://www.os2museum.com/wp/wp-content/uploads/2020/01/P117...
It looks like a camera but it surely isn't, so what is it?
You can see the two pairs of enamel wires coming out on each side the sides. There are two windings, both wound on a core spool with its axis perpendicular to the board.
What you're seeing looking like the lens of a camera is a hole in the middle of the spool, presumably used during manufacture to hold it while winding.
https://web.archive.org/web/20201026081303/https://www.os2mu...
> The CTI provides all the MAU (transceiver) functions except for signal and power isolation. Signal isolation can easily be provided by a set of three pulse transformers that come in a single Dual-in-Line package. These are available from transformer vendors such as Pulse Engineering (PE64103) and Valor (LTll0l). However, for the power isolation a DC to DC converter is required.
The data sheet provides several sample implementations using a PE64018, PE64103, PICO 33223, or PICO 33143 for this.
[1] http://www.bitsavers.org/components/national/_dataBooks/1988...
"Detected 3Com 3c501 (THROW IT AWAY!!!)"
which is the most deprecating thing I can see the 3c501 driver code printing, in quickly skimming through old versions of the right age (it seems to have been mostly unchanged for large swathes of time).
(I went skimming for this message out of morbid curiosity, and couldn't find it. But I did only specifically look in the 3c501 source, so maybe it was a closely related card doing it, or a not-in-kernel version of the driver?)
Back as a student when I moved into the dorms which had 100base-T, I did some googling (or maybe it was altavista'ing in those days, I can't remember) and it seemed the best regarded 100base-t cards for Linux were the Intel one and the 3com one. The 3com one was slightly cheaper at the local computer shop, so I got one of those.
(Somewhat later on there was a flood of very cheap DEC Tulip clones, and I got one of those too. Was happy with that one as well.)
I put out a number of Red Hat 6.2-based servers w/ the Intel NICs, got hit with the dreaded eepro100 "receiver lock-up" bug, and had to end up putting in 3C905 NICs in their place to get stable network connectivity. Good times. >smile<
[1] https://universaldatasystems.org/shop/product/intel-pro-100b...
I did some testing on them and it turned out they sent an interrupt signal on every IRQ regardless of what IRQ you configured in the setup utility which caused windows to lock up.
I took them home and drilled through the traces to the unwanted IRQs on the ISA slot and gifted them out at lan parties.
https://en.wikibooks.org/wiki/QEMU/Devices/Network
virtio > e1000 >> rtl8139 >> anything else with one of the ne2K variants as the sound-blaster like minimum compatibility level.
As I recall, he talked about a state machine triggered that needed a ... memory? I/O? ... read that would get as many wait states (ahhh, wait states! kids these days...) as needed to guarantee it was done. But the Linux driver would not do the read because, he said, it always returned the same value anyway. As it would, if you did.
Linux NIC troubles were self-inflicted.
In contrast, the NE1000
did not map its onboard SRAM into the host’s address space
, but likewise
removed the DMA support,
and only supported PIO transfers that utilized the DP8390’s Remote DMA feature. That meant the NE1000 only required 32 bytes of I/O port space and an IRQ; no other resources were needed. The NE1000 was priced at $495 at introduction (3Com’s EtherLink 3C501 cost $595 at the time) but almost immediately dropped to $395 (just below the WD8003).
The comparison between the WD8003 and NE1000 is interesting. WD opted to use shared RAM which is faster but significantly more problematic to configure, and that was especially the case with the coming wave of 386 memory managers. Novell went in the opposite direction, choosing somewhat slower PIO but completely avoiding any configuration issues with shared memory.
Both Novell and WD decided to
drop DMA support,
probably because it avoided yet another source of configuration conflicts and because especially on PC/AT class systems, DMA was slower than either PIO or memory anyway.
It is important to keep in mind that the existing competition for the WD8003E and NE1000 weren’t fancy adapters like the 3Com 3C505 EtherLink Plus or the Exos 205T but, first and foremost, the cheapest Ethernet option available, the 3Com 3C501 EtherLink. And both the NE1000 and the WD8003E beat the 3C501 hands down, because they had a much bigger packet buffer (8K vs. 2K) and did not have the awful 3C501 limitation of having to switch between mutually exclusive transmit, receive, and host access modes.
In 1988, the NE2000 appeared. It was essentially a 16-bit version of the NE1000 with support for 16-bit AT bus (but still capable of working in 8-bit slots) and two SRAMs in an 8Kx16 configuration. This doubled the onboard memory capacity and enabled both the DP8390’s internal bus and the NE2000’s external ISA bus connection to use 16-bit transfers, significantly improving the speed at which the host could communicate with the adapter.
Western Digital released a similarly upgraded WD8013E (EtherCard Plus 16) with a 16-bit ISA interface and 16KB of onboard RAM.
On the part of Novell, the motivation was clearly not to make money on hardware but sell more software. In 1991, Novell let Anthem/Eagle take over the network card manufacturing and distribution; after all, the hardware business was something Novell wanted to get out of, not into. The main purpose of the NE1000 and NE2000 was to drive the prices of networking hardware down, and it did just that."