I recently did a benchmark of both throughput and CPU load of 10MbE NICs under old Knoppix using iperf, which was available on my Knoppix (iirc also 5) and also saw disastrous results for most ISA NICs, with most NICs able to send a P3-500 to 100% load trying to push through a paltry 8Mbps. Tellingly there was no difference with designs supporting DMA or shared memory. My strong suspicion is that Linux drivers for ISA nics are woefully primitive and just using the most basic - and CPU-intensive - IO possible. The one exception, 3C509, seened to underscore that point: despite being an unremarkable design, it vastly outperformed the rest in terms of CPU usage without less throughput. That driver obviously does work...

My guess it that it's your CPU limiting performance here. To check that, run top in another window while doing your speedtest. If I'm right it should shoot past 97%. If so, performance in another OS with better drivers might be (far) better.

Don't forget that ISA on newer systems (past 486) is slower. This can be easily shown by using an ISA video card on a newer than 486 system that has ISA slots.

I have three different brands of 100 mbit ISA ethernet cards - 3com (same as yours), Intel, and IBM. The IBM one uses the Intel chipset, but with its own drivers (Intel drivers won't work on it). In practice, I have found 100 mbit ISA cards to be roughly 2-3x faster than 10 mbit ISA cards, but nowhere near the 100mbit limit. It was enough of a difference for me to upgrade all machines that use ISA ethernet with 100 mbit cards.

dionb wrote:

My guess it that it's your CPU limiting performance here. To check that, run top in another window while doing your speedtest. If I'm right it should shoot past 97%. If so, performance in another OS with better drivers might be (far) better.

There may be something to it.
During transfer, top shows about 85% CPU in "hi" (servicing hardware interrupts), and only about 2% "id" (idle).

However, if there's something wrong with Linux here, Windows is even worse - I just tried it with Windows 98SE, with Win32 port of wget (wget -O nul ftp://...), and it only achieves about 1.33 MB/s.

Can you run the same tests with a 10 mbit 3Com Etherlink III?

feipoa wrote:

In practice, I have found 100 mbit ISA cards to be roughly 2-3x faster than 10 mbit ISA cards, but nowhere near the 100mbit limit. It was enough of a difference for me to upgrade all machines that use ISA ethernet with 100 mbit cards.

Any details?
I mean, what CPU, what OS, and how was the speed measured?

feipoa wrote:

Can you run the same tests with a 10 mbit 3Com Etherlink III?

Yes, in a few days, when I'm done experimenting with 3C515, I can replace it with a 3C509B...

feipoa wrote:

I have three different brands of 100 mbit ISA ethernet cards - 3com (same as yours), Intel, and IBM. The IBM one uses the Intel chipset, but with its own drivers (Intel drivers won't work on it). In practice, I have found 100 mbit ISA cards to be roughly 2-3x faster than 10 mbit ISA cards, but nowhere near the 100mbit limit. It was enough of a difference for me to upgrade all machines that use ISA ethernet with 100 mbit cards.

That tracks given the normally quoted three tick cycle time for 16 bit transfers.

So, replaced the 3C515 with a regular 10 Mbps Ethernet NIC:
3Com EtherLink III (3C509B-Combo), using RJ-45 port

Linux:

Server -> Client: 891 KB/s
Client -> Server: 917 KB/s
CPU usage during download: 35% hardware interrupts, 45% idle

Windows:

Server -> Client: 1002 KB/s

Conclusion:
100 Mbps is faster than 10 Mbps, even on ISA - but in my case the speedup was only about 50%

Not sure about the speed. But you can avoid the FTP by using netcat. Something like:

On one end:

nc -l 8888 > /dev/null

on the other side:

dd if=/proc/kcore bs=1000 count=1000 | nc <ip> 8888

Then you can experiment with block size

Only 50% faster. Hmm... Its possible that I used an underpowered computer for the 10 mbit and a much faster computer for the 100 mbit. I'd have to run these tests again.

Random fact:
3C509B doesn't use DMA, 3C515 does

I suspect DMA may help a lot in certain configurations...

Grzyb wrote:

Random fact:
3C509B doesn't use DMA, 3C515 does

I suspect DMA may help a lot in certain configurations...

You are right. I confirmed on the pcb for 3c509b. I wonder how they got the CPU usage down when running 3c509b? Optimized driver?

Wasn't this card designed around/for windows NT environments? I have one of these cards in front of me and i'm curious now.

Also with late isa cards like this, I find its very helpful to assign it all the irq/dma requirements in the BIOS. Dont let the OS use PNP. Linux might do it better, and i'm sure one of you is waiting for an opportunity to tell me, but I've had much better success with a manual assignment.

1.4MB/sec looks pretty close to what ISA IDE cards get for data throughput. BIOS disk routines use a REP INSW instruction to read sectors from the IDE port. Maybe network drivers are also using this. I imagine that ISA DMA using the 8237 wouldn't be any better, since the DMA controller was spec'ed at half the ISA clock in the AT.

Judging by the performance achieved by ISA video cards, a memory window that could be read using REP MOVSW would probably be somewhat faster. I wonder if any ethernet cards use such a setup. I recall reading that an IDE interface for 8-bit machines or the PC Jr. or something used memory-mapped, mirrored registers to get better performance on 8088s that lack INSW.

Now I am also wondering if pre-allocating a space in write-back cache on 486 systems for the destination memory area (by reading it ahead of time) would make ISA I/O go faster by getting the bus cycles closer together.

How about overclocking the ISA bus? (usually makes sound cards unhappy though)

Per manual on the 3c509b, it says it allows up to 10mhz bus clock.

I run an 3C509B at 13.3MHz and no wait states very happily in one of my 486 machine, and on another 386 machine a slightly newer version that has Parallel Tasking written on the chip at 16MHz.

Simple DMA is actually slower than PIO. What these cards need is Bus Master DMA. As we know ISA Bus master is a kind of black magic.

I'd check if it is enabled. Run the config tool for the card in DOS and make sure it is on and there is DMA channel set. Looking into 3C515.c source code, it looks like the bus master mode can be forced by module option.

In general as far as early ISA cards in Linux, the bus master is known to be the most reliable with DEC 21040 or AMD Lance chipset.

bakemono wrote:

Judging by the performance achieved by ISA video cards, a memory window that could be read using REP MOVSW would probably be somewhat faster. I wonder if any ethernet cards use such a setup.

Yes, there are such cards, eg. 3C507
But not 3C509B nor 3C515 - they only use memory address space for Boot ROM.

mpe wrote:

Simple DMA is actually slower than PIO. What these cards need is Bus Master DMA. As we know ISA Bus master is a kind of black magic.
I'd check if it is enabled. Run the config tool for the card in DOS and make sure it is on and there is DMA channel set. Looking into 3C515.c source code, it looks like the bus master mode can be forced by module option.

So I did some more tests...

modprobe 3c515 options=7 (media type autoselect):

wget: 1.45 MB/s
put: 1413 KB/s

modprobe 3c515 options=15 (media type autoselect, full duplex):

wget: 1.55 MB/s
put: 1418 KB/s

modprobe 3c515 options=23 (media type autoselect, bus mastering):

fails to work!

modprobe 3c515 options=31 (media type autoselect, full duplex, bus mastering):

fails to work!

So, two important conclusions:
* even though the card claims to support NWay, it doesn't run in Full Duplex by default, and it's a good idea to enable FD
* bus mastering on ISA is black magic indeed, and this computer obviously isn't magical, it's even mentioned in the docs that "Some computers do not fully support bus mastering...", along with instructions how to disable bus mastering with NDIS and ODI drivers

I think I'm done with testing 3C515 on this machine.
I'm going to give it another try when I have a machine this card was actually intended for, ie. some pre-PCI 486...