Confirm that the FTP client is from mTCP?

It seems that the issue is related to disk performance (PIO mode).
I had same low speeds in Windows 98 SE, but when I enabled "DMA" I achieved 100Mbps when copying files from FTP.

Have you tried using other network speed measurement utilities that don't involve the disk?
There should be utils like iperf3 for DOS, but I'm not sure.

FTP gives you a nice, real-world measure of performance but it also is measuring disk performance.

If you are going to test using FTP, then ensure the target file is on a RAM drive, especially if you are using a mechanical hard drive. Even testing with some sort of FLASH based drive leads to a lot of extra memory copies which have nothing to do with the network card performance.

If you are going to test with FTP, ensure you are using the largest disk buffer and TCP buffer sizes that you can. (Well, usually - a more detailed benchmark is needed to determine those.) If you are using mTCP those are configuration settings in the MTCPCFG file.

Even smartdrv (you have to pass C+ to it to enable write caching) might help as well.

FWIW I did some transfer speed tests with a packet driver and 10mbs NICs/hub using a very low overhead transfer method (raw packets) a while back:

DDLINK: Easily move files between/To/From DOS systems

ott wrote on 2026-04-14, 16:34:

It seems that the issue is related to disk performance (PIO mode).

yes! There are some DOS DMA drivers for intel chipsets, those might help, and mentioned smartdrive.
DOS means every IO is blocking.
In PIO CPU just sits there spinning in circles waiting for byte after byte from/to HDD. NICs manually copy data there and back instead of using DMA masters they were designed for.

konc wrote on 2026-04-14, 16:08:

At this point I'm assuming a combination of lazy drivers for a dead platform

yes

konc wrote on 2026-04-14, 16:08:

and cards with a design targeting other OS and being impossible to perform under DOS.

Not exactly.
Not to mention RTL8139 has the worst interface for transferring data from almost all contemporary 100mbit chips 😀 Re: Why are 3Com NICs in such high regard?

1 * The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is
2 * probably the worst PCI ethernet controller ever made, with the possible
3 * exception of the FEAST chip made by SMC. The 8139 supports bus-master
4 * DMA, but it has a terrible interface that nullifies any performance
5 * gains that bus-master DMA usually offers.
6 *
7 * For transmission, the chip offers a series of four TX descriptor
8 * registers. Each transmit frame must be in a contiguous buffer, aligned
9 * on a longword (32-bit) boundary. This means we almost always have to
10 * do mbuf copies in order to transmit a frame, except in the unlikely
11 * case where a) the packet fits into a single mbuf, and b) the packet
12 * is 32-bit aligned within the mbuf's data area. The presence of only
13 * four descriptor registers means that we can never have more than four
14 * packets queued for transmission at any one time.
15 *
16 * Reception is not much better. The driver has to allocate a single large
17 * buffer area (up to 64K in size) into which the chip will DMA received
18 * frames. Because we don't know where within this region received packets
19 * will begin or end, we have no choice but to copy data from the buffer
20 * area into mbufs in order to pass the packets up to the higher protocol
21 * levels.
22 *
23 * It's impossible given this rotten design to really achieve decent
24 * performance at 100Mbps, unless you happen to have a 400Mhz PII or
25 * some equally overmuscled CPU to drive it.

yet its the fastest for you thru shear brute force of CPU.
Its possible 3com and Intel didnt implement the primitive IO/memory mapped access methods and DOS drivers must perform some elaborate dance programming NICs DMA engine to transer every single packet from some fixed buffer while Realtek allows its stupid chip be accessed any way developer wanted.

konc wrote on 2026-04-14, 16:08:

I know that in practice you can't saturate 100Mbps under pure DOS+packet driver, let alone with such a system.

Yes you can!
I often use a Celeron 266 - completely castrated off the L2 cache! - to test things, and it's already enough to score 11 MB/s.

Two things to remember:
- "MTU 1500" in %MTCPCFG%
- when testing the NIC, don't test the HDD - always download to NUL, eg. "get SomeBigFile.zip nul"

Some packet drivers are of poor quality, but I can't recall any problems with the RTL8139 series.

Grzyb wrote on 2026-04-15, 06:09:

... when testing the NIC, don't test the HDD ...

Most of my test systems have a good sized RAMdrive.
Very fast, lets me verify data transferred, and auto-cleans at shutdown!

DaveDDS wrote on 2026-04-15, 11:10:

Most of my test systems have a good sized RAMdrive.
Very fast, lets me verify data transferred, and auto-cleans at shutdown!

Yes, RAMdrive is also a good idea - if only you can install enough RAM.

Usually I don't bother adding RAM to old machines, and simply download to NUL for benchmarking.
This way I can exercise the NIC with a several-gigabyte-long file even in a 16-bit PC.

Maybe I should have worded it differently because nobody posted numbers of actually writing files with machines of this era, the real world scenario, not how to benchmark the network. What's the speed you get when transfering, let's say, an .ISO file using FTP under pure DOS+packet driver and with what card?

I'm asking for specific numbers because I see extreme inconsistencies in this scenario, and I feel some people might also be surprized with them. Check out this example,

Intel Pro/100: downloads and writes with 2.3MB/s, but saturates the 100Mbps when downloading to NUL achieving almost 10MB/s.
Same PII/300 and everything with the 3Com: downloads and writes with 1.5MB/s, but when downloading to NUL speed stays exactly the same ~1.5Mb/s. Could it be maxing out the CPU? Probably not because with a CPU 3x faster it marginally improves. May be it's storage limited, a modern SSD with a SATA-to-IDE adapter? Again I doubt it because it's downloading to NUL and, besides, another card can write times that. (FTP client/server used, disk caching, ramdrives etc don't change anything, they're clearly not a limiting factor)

At this point and after getting these weird results I'm convinced that some cards have completely broken packet drivers, or their design limits them when there's no DMA because under Windows they have minor differences.

That's why I wanted to build a list of cards and their numbers under DOS. Maybe ~2MB/s is the speed commonly achieved? Maybe 4 is the best one will ever get or there is an even faster card? Maybe someone didn't know he can get 4 and now he does, or maybe someone is stuck with 1.5 like I was and now finds out that it's on the slow side? These kind of things. Again, not trying to improve anything, just document and confirm the numbers.

Packet Drivers for 3Com PCI cards are known to be buggy - sometimes an older version works better...

Joseph_Joestar wrote on 2023-02-01, 17:55:

I have a 3C905B-TX card and would like to try it, since I'm getting craptastic speeds with packet driver 5.2.6.

Joseph_Joestar wrote on 2023-02-02, 10:09:

Grzyb wrote on 2023-02-02, 04:53:

The PD version is 4.0d

Awesome, this packet driver version seems to be working best for my particular card. Thanks again!

Grzyb wrote on 2026-04-17, 09:09:

Packet Drivers for 3Com PCI cards are known to be buggy - sometimes an older version works better...

Joseph_Joestar wrote on 2023-02-01, 17:55:

I have a 3C905B-TX card and would like to try it, since I'm getting craptastic speeds with packet driver 5.2.6.

Joseph_Joestar wrote on 2023-02-02, 10:09:

Grzyb wrote on 2023-02-02, 04:53:

The PD version is 4.0d

Awesome, this packet driver version seems to be working best for my particular card. Thanks again!

Oh wow, that's the kind of info I was hoping for with this thread, off to check some versions now!