I'll have to recheck but I'm pretty sure I did significantly better than 25Mbit with the 3C597. IIRC I was getting in the low 40s on NT4

This project - https://github.com/jfabienke/3com-packet-driver - claims much better throughput for the 3C515.
But not tested on real hardware - oh well, I'm waiting for the release...

Grzyb wrote on 2025-11-02, 16:34:

This project - https://github.com/jfabienke/3com-packet-driver - claims much better throughput for the 3C515.
But not tested on real hardware - oh well, I'm waiting for the release...

Didn't we discuss that project here: Re: DOS packet drivers for 3COM 3C515-TX?

Not sure it is buildable in its current form - there seemed to be quite a few long filenames in the source unsupported in DOS, when someone tried to build it the makefile generated a load of errors - plus it referred to includes which don't exist in the Git repo.
Without any evidence, I don't know if it's actually real or has been built - or how big it actually is; there's an enormous amount of source (assembly and C) included - considering the tiny size of most existing packet drivers. But there's no logs or screengrabs to show it running, unfortunately.

The documentation seems to refer to the driver as both '3CPKT.EXE', '3CPD.COM' or '3CPD.EXE' depending on which section you read. The supported command line arguments also seem to change from section to section.

I don't want to say that this is all completely AI generated, but chunks of the docs read as though they have been produced by an LLM.

If someone is able to build it, and it works as described then I'll eat humble pie... but the first step is someone actually building it.

I think we can see that a lot of the content of that driver repo is being AI generated:

https://github.com/jfabienke/3com-packet-driv … /code-frequency

https://github.com/jfabienke/3com-packet-driv … hs/contributors

Claude (https://claude.com/product/claude-code) made 224K additions and 155K deletions after the initial commit. The amount of AI generated content would make me extremely wary.

Indeed - I'm also afraid that project looks too beautiful to be true.
But I want to be wrong...

Doesn't build, even on Linux with long filenames - the Makefile is broken:

1$ /opt/toolchains/x86/watcom/binl/wmake release
2Open Watcom Make Version 2.0 beta Mar  1 2025 02:31:41 (32-bit)
3Copyright (c) 2002-2025 The Open Watcom Contributors. All Rights Reserved.
4Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
5Source code is available under the Sybase Open Watcom Public License.
6See https://github.com/open-watcom/open-watcom-v2#readme for details.
7Makefile(203): Error(E24): More than one command list found for (PRODUCTION)
8Makefile(210): Error(E21): Extension(s) (.PHONY) not defined
9Makefile(210): Error(E09): Ignoring out of place Path Specifier
10Makefile(210): Warning(W79): Makefile may be Microsoft; try /ms switch
11...
12...
13Makefile(270): Warning(W18): Unrecognized or out of place character '='
14...
15...
16Makefile(272): Warning(W18): Unrecognized or out of place character ','
17...
18...
19Makefile(272): Warning(W18): Unrecognized or out of place character '='
20...
21...
22Makefile(309): Warning(W18): Unrecognized or out of place character '|'
23Makefile(399): Error(E24): More than one command list found for (build/%.obj)
24...
25...
26Makefile(526): Warning(W18): Unrecognized or out of place character '|'
27Makefile(590): Error(E24): More than one command list found for (verify-patches)
28Error(E02): Make execution terminated

I cut out the repeating errors. But the Makefile clearly isn't formatted to work with wmake from Open Watcom.

Unless by "Open Watcom C/C++ 1.9 or later" it actually means "only builds with Open Watcom 1.9+ and < 2.0". I'll try installing an older non-2.0 version of Open Watcom, as I'm aware of the large codebase change between them - but I have my doubts.

maxtherabbit wrote on 2025-11-02, 15:29:

I'll have to recheck but I'm pretty sure I did significantly better than 25Mbit with the 3C597. IIRC I was getting in the low 40s on NT4

Do you remember which system you had?
I have used a 486DX at 50 MHz.
256 kB L2 cache
32 MB RAM
Adaptec 2740W SCSI controller
EISA bus at 8.33 MHz.

Grzyb wrote on 2025-11-02, 12:57:

This card is "100 Mbps Signaling Rate" - but only 15 Mbps throughput 🤣

Yes, that also came to my mind.

mkarcher wrote on 2025-10-22, 19:34:

Some data point from my Am386DX-40 system, with an Adaptec 1542CF running at an ISA DMA transfer rate of 8MB/s. The hard drive in that system is a Fireball 1080S, which is not necessarily known for its superior speed.

I have a very similar thing - only my drive is IBM DCHS09F.

ASPI4DOS.SYS loaded, "Int 13H routed through ASPI manager."
FAST SCSI enabled for all devices - but there's practically no difference compared to FAST SCSI disabled!
DMA Transfer Rate = 5.0 MB/s (default)

DMA Transfer Rate = 5.7 MB/s

DMA Transfer Rate = 6.7 MB/s already causes DOS to hang on boot

I guess 1863 KB/s in FTP isn't that bad, after all.
For notably more, I would need that elusive super-DMA, and a NIC with the option to make use of it.

I'm almost ready to accept that the max for normal ISA is 2+ MB/s, but I still have doubts...
What's the meaning of the "3.3 MB/s" in IDE PIO Mode 0 ?
And note that my ISA video memory scores almost 4 MB/s !

Perhaps instead of struggling with bus mastering, they should have placed the NIC's buffer in the memory address space?

In case somebody was curious, the SMC Elite Ultra 8216T has a memory buffer in address space.

I NATed with freesco 0.2.7 (kernel 2.0.38) on a DX4-100 and two of these ISA cards a decade or two ago at wire speed (10 half - just over 1000KB/sec) without the cpu breaking a sweat at all. That is 2MB/sec over the ISA bus with more than enough time to spare to keep the system snappy responsive.

These are excellent cards.

The highly regarded 3c509 (even the ParallelTasking B version) sucks terribly in comparison. I could never understand why everybody seems to like them so much.

I think the reason 3c509 is so recommended is because of the driver support for virtually every OS under the sun. They work everywhere and are really easy to source.

In my part of the world 3c509's are not that ubiquitous. I own exactly one.

When I got it I was very excited, as my association with 3com was with the much better 905 pci. It has been nothing but disappointment.

This country used to be NE2000 clone territory. At least your expectation of a NE clone is low, and its performance not at all too bad with the same wide support.

Dear st31276a,

Im really keen to understand the advantage of that SMC cards. Reaching 1000kb/s via ftp on a dx4 is per se not a clear advantage. Memory buffer in address space is indeed an advantage or improvement but it has to be visible in delivered results of the NIC at the end. Also no busmaster support etc.

Don’t get me from I don’t want to defend 3com or whatever. I am just reelle curious about the real world advantage of these cards.

Would appreciate details 😀

Thanks

The real advantage of network buffere in memory space is transfer efficiency over the ISA bus, not transfers over the ethernet wire.

The 3c509 hog the cpu while doing bus transfers. The 8216’s do the same thing quicker, at lower average cpu time consumption.

If the only goal is to transfer data that already exists in files and you have an efficient means to read/write those files, the measurable performance differenxe of the overall system could probably be small. However, if the server processes any kind of dynamic workload in order to produce the data that is transferred, it will make a much bigger difference.

I used this DX4 as a NAT router in the 2000’s when I was in university residence. It also performed duty as an ftp server for about 15 users and a web server running a simple forum on php4 with mysql 3.23. It also graphed network traffic with mrtg / rrdtool.

It had an 8216 pointing to the outside lan (which was a 10Mbps HD hub at the time) and an 8216 pointing to my spiffy new Willamette desktop. It also had a third nic (DE220 ne2000 clone) pointing to a third computer, as I did not have a hub or a switch at the time.

I only got the 1000KB/sec transfers to the P4 late at night when the outside network was quiet, of course, but it was indeed possible and the 486 took it really easy while nothing else hitched. The forum was not running significantly slower than it already was on the 486, for instance, while NATing tcp flows.

However, when I did full speed transfers through the ne card, things did slow down a bit.

As my network grew, I found the 509 card with some pentium that did openvpn duties elsewhere. I had high expectations of the card, but it disappointed me from day one. It holds the host system hostage when suffering to transfer more than 750KB/sec.

I currently have it in my 386DX-33 and it does not go faster than 400KB/sec. It’s quite ridiculous. I think it has mainly to do with the pio bus transfers.

Edit: tl;dr: With PIO you are lucky to get 2MB/sec over the bus. With memory read/write its easy to get 4. This means driving two cards at full speed will be all the system is doing with PIO, while it will have 50% free time with MMIO. Makes the world’s difference.

Thanks. I learned something new indeed as I understood so far that only busmaster Dma can efficiently decrease cpu usage.

I think the smc is mainly using 16kb of memory adress space for its buffer. So if mainly working with „blocks“ <= 16kb I can imagine the benefits. Reminds me of a current cross thread topic here with memory mapped transfers for video/hdd. The message there was indeed that MMIO can increase bandwidth by 33% for single workload (ISA cache ide controller bandwidth).

Would have potential to compare MMIO vs DMA busmaster driven IO with regards to cpu usage and transfers.

Thanks again.

Yes, it has a 16KB buffer that is mapped to memory. Since ethernet packets are 1500 bytes at most, it is plenty of space. The driver manages the TX/RX buffers in that window, there is enough memory for 8 of each. The card can receive while the system is otherwise tied up and it can move large chunks at a time.

I would also be curious to know how busmaster IO would compare. Since busmastering ISA is not simple, I think the low hanging fruit worth exploring is MMIO instead of PIO for other slow things such as IDE transfers, as currently ruminated upon in another thread. Not that it’s going to be straightforward, but definitely more doable than bus master.