Grzyb has had some success with making a similar setup go faster; it's in the forum archives here somewhere.

Things to look for:

• Ensure the mTCP MTU is 1500
• Ensure the ODI driver has plenty of buffers/packets, and that they are at least as bit as the Ethernet MTU.

I suspect packets are being dropped at the transition from ODI to the packet driver. Ensuring you have enough buffering at the ODI layer is important for avoiding packet drops. You can check the packet drop statistics using the PKTTOOL program in mTCP.

You could try the DIS_PKT shim over the NDIS driver, see if that's better

Looking at NET.CFG I have 16 buffers of 1600 bytes. In MTCP.CFG the transfer unit is 1500 and the FTP server read/write buffer is 16kb, with 8 packets per poll.

After I do an ftp put ~10MB of files to the laptop I ran PKTTOOL and it it showed 0 errors in or out, and 0 dropped packets.

Interestingly, if I do a get from the laptop to a modern machine I can hit 13 Megabytes/sec. The other direction it's never more than 1.1-1.4 Megabytes/sec. So the behaviour is unidirectional.

Have a look at my drop-in replacements for PD - Re: Loading DIS_PKT9.DOS, but not from CONFIG.SYS

For the ODI, "buffers 16 1600" should be enough.

My preferred benchmarking procedure is using mTCP FTP client:

ftp <modern server IP>
bin
get SomeBigFile.zip nul

...which avoids old disk I/O.

And I believe I have some 1 Gbps 3Com card, with a Broadcom chip - will try it later myself...

I'll give the to-null transfer a try first thing in the morning. I did wonder if it was disk speeds, but I'm using a fairly modern WD120BEVE, which is ATA100 and pretty damn fast.

I will certainly try your alternative - NDIS drivers have always eluded me in their jump-through-hoops setup, so that looks like a neat way of doing it and bypassing config.sys.

Even downloading (from server to laptop) to the NUL device and bypassing the disk, the transfer speeds are still pegged at just over 1 Megabyte/sec:

The other direction (laptop to server) I see more appropriate speeds (just under 10 Megabytes/sec), while certainly not gigabit I don't think I'd expect that level from DOS reading from a 2.5" laptop drive... they're definitely figures that I'd be happy with to do bulk transfers though - especially if I could replicate them in the other direction:

I'll try the NDIS drivers next.

I can report that the NDIS driver/bat method does work - this is using B57.DOS and the necessary changes to protocol.ini and ndis.bat .... but the download speeds are unchanged; still no more than 1.1 Megabytes/sec.

I don't know if this information will help:

I must have had one of these NICs at one point, because it is included in
the bootable ImageDisk diskette image.

When I boot that diskette and run PKTDRV and select "Broadcom B57xx" it
unpacks:

1B57.COM       23,542
2LSL.COM       18,356
3ODIPKT.COM     3,307
4NET.CFG          461
5START.BAT         61

> NET.CFG<

1Link Support
2; Max Stacks 8
3; Max Boards 4
4; Buffers 30, 1514
5 buffers 6, 1600
6
7Protocol IPX
8 Bind B57
9
10Link Driver B57
11; Frame Ethernet_802.2
12; Frame Ethernet_802.3
13; Frame Ethernet_II
14 envelope type ETHERNET_II
15; Frame Ethernet_SNAP
16; CONNECTIONTYPE AUTOSENSE
17; FLOW_CONTROL ENABLE
18; HALFDUPLEX
19; FULLDUPLEX
20; SPEED 10
21; SPEED 100
22; AUTO
23; PCISLOT 9
24
25;NetWare DOS Requester
26; FIRST NETWORK DRIVE = F
27; NETWARE PROTOCOL = NDS BIND

>START.BAT<

1@echo OFF
2loadhigh LSL
3loadhigh B57
4loadhigh ODIPKT 0 96

You can get these original files on the ImageDisk bootable diskette image,
available at "Daves Old Computers"

Yep, those are the files I'm using. I tracked down the latest B57.COM (dated 2007), as the version I was using originally was a couple of years older - sadly it made no difference.

It all works reliably - MTCP has no issue issuing a DHCP request, and neither the FTP or FTPSRV tools have any problems. It's just this really odd asymmetric speed thing; ten times the transfer speed in one direction compared to the other.

I've tried playing with buffers in config.sys, I've now got an UDMA driver and disk cache running (UIDE.SYS) to see if it was disk performance, but it makes almost no difference (though it is a bit snappier overall in terms of disk performance, so I'll probably leave those changes in place).

What I suspect I need to do next is try to get a more modern OS running and see if the bandwidth issues are still there under a different TCP/IP stack and Ethernet card driver. If I can find small enough live Linux iso that runs well enough in 1GB RAM with this Pentium-M cpu that would be a good start.

Using an older Ubuntu i386 server install iso image which boots in the 1GB of RAM fitted to the laptop....

The Broadcom tg3 driver (used for BCM57xx devices) will not load and complains about possible firmware issues. That's really, really odd. I do wonder if it's a symptom of an underlying issue with the onboard NIC and/or its firmware settings.

So I've installed a 3C996B-T, based on BCM5701TKHB.
It's a 64-bit PCI card, but I'm using 32-bit slot.
CPU: Celeron 266
cable: UTP CAT.5E

mTCP FTP client
MTU 1500
NDIS and ODI shims - as linked in my previous post.

NDIS:

B57.DOS v6.32 (030220)
by default it links at 100 Mbps FullDuplex !!!

FTP GET to NUL: 5580 KB/s

after adding "LinkSpeed=1000" to PROTOCOL.INI it doesn't link at all !!!

ODI:

B57.COM v6.02 (021403)
by default it links at 100 Mbps FullDuplex !!!

FTP GET to NUL: 5194 KB/s

Windows 98 SE:

links at 1 Gbps

FTP GET to NUL: 3781 KB/s

Linux Knoppix 5.0.1:

links at 1 Gbps

FTP GET to /dev/null: 15662 KB/s
wget -O /dev/null: 19.53 MB/s

megatron-uk wrote on 2025-09-11, 11:58:

I tracked down the latest B57.COM (dated 2007)

Where?

Grzyb wrote on 2025-09-11, 12:36:

megatron-uk wrote on 2025-09-11, 11:58:

I tracked down the latest B57.COM (dated 2007)

Where?

It's on the Lenovo support page here: https://support.lenovo.com/co/en/downloads/ds002857

Package is 7rd02ww.zip, there's NDIS2 and Netware (ODI) versions. Startup banner looks like this:

Actually... I've just noticed that the MAC address is clearly gibberish.... how did I not see that before? Is that a smoking gun to an underlying firmware problem perhaps???

EDIT: Just checked the IBM BIOS screen and it too is reporting a MAC address of all blank. Urgh.... computers... who'd have them?

NDIS2 Driver v10.4.6 (070524) :

links at 1000 Mbps FullDuplex
FTP GET to NUL: 5112 KB/s

ODI Driver v10.4.7 (070713) :

links at 1000 Mbps FullDuplex
FTP GET to NUL: 5250 KB/s

ODI driver v1.06 (102601) :

links at 100 Mbps !!!
FTP GET to NUL: 6925 KB/s

The latest drivers can finally work at 1 Gbps.
Nevertheless, the fastest is the earliest driver.

It is interesting (to me) hearing people complain about not getting gigabit to
work on DOS/Win9x systems... So many nowadays don't know much about the history
of networking or how it came to be what it is.

I've been involved in networking before ethernet was really a thing. I worked
at companies with "big iron" (IBM 360, Vax etc.) which all had their own
proprietary networks - worldwide it was packet based networks (like Datapac
here in Canada - which I worked on).

As I began to build a basement full of various systems and wanted them to talk
to each other - I developed a serial data-switch which allowed me to connect
them all into a common unit and do things like file-transfers at a whopping
19,200bps serial speed - These eventually became the Enfin->NewBridge 10xx
series of RS-232 data switches.

When I first encountered ethernet, it was a godsend ... a 10 megabit coaxial
cable link shared by all your systems, I couldn't believe how fast it was!
Eventually these became twisted-pair hubs which had seperate cables to each
system, but they were logically all on the same shared wire. You can usually
tell these early hubs as they often/usually have a BNC coax connection for
connecting to existing older networks.

(Btw - the term "ethernet" originally came from radio networks where systems
shared the same channel "in the ether")

Then we got switches - looked the same, but data between two systems no longer
took bandwidth from other systems - now you could maintain a full 10mbps
transfer even when other systems were busy on the network.

I used 10mbps networking for many years (still do in some offshoots).

Then along came 100mbps - awesome speed - I never really noticed/cared that
much, as most of my transfers were small... but it became the new standard, and
I eventually upgraded my main switches to 100mbps.

Now I have a fibre internet connection, and I believe the main router (from the
phone company) is gigabit - but I've never felt need/desire to upgrade the rest
of my network. (few times I've done speed tests, I don't think I've ever seen a
connection to "the world" maimtain even close to 100mbps).

My DOS systems are one one of the 10mbps offshoots of my network. I don't
use them on networks much, the only one I do is the ImageDisk system.

When I sold off the original ImageDisk system (where I developed it), enough
people have wanted me to continue supporting it that I dug out a spare mainboard
I still had for it and put together another one. This one didn't have a network
card and I foolishly though I could just serial transfer images with DDLINK.
A 1.5m image takes minites to transfer!

So I dug around and found an NE2000 10m network card. Using DDLINK the images
now transfer in less than 2 seconds. This is almost always to/from a more
modern system running DDLINK within DosBox.

-

Give that you mentioned using a DOS packet driver, I'm assuming that you are using DOS (or some other very early OS)
Which makes me curious... what are you doing that needs gigabit transfers in DOS and a couple megs/second isn't enough?

DaveDDS wrote on 2025-09-11, 15:12:

Give that you mentioned using a DOS packet driver, I'm assuming that you are using DOS (or some other very early OS)
Which makes me curious... what are you doing that needs gigabit transfers in DOS and a couple megs/second isn't enough?

Yes, using DOS. Exclusively. I have a number of older laptops (from Pentium 1 up to these later Pentium-M designs, like the Thinkpad T43) that I evaluate and use for DOS gaming - with the advent of SBEMU and VSBHDA the options for mobile DOS gaming natively have increased massively - I used to be on a never-ending search for 'perfect' period laptops with DOS-supported sound hardware and decent screen scaling, but that is blown wide open with SBEMU and VSBHDA and more modern laptops which do full screen interpolated scaling for free.

My usual route of prepping a new machine is to do a minimal boot from a Win 98SE 3.5" floppy, fdisk, format (fat32) and sys the drives (most of the time these are either 128GB mSATA or as with the Thinkpad here, a 120GB 2.5" IDE). Then I have another 3.5" floppy that contains MTCP and a range of packet drivers to bootstrap the rest of the install (memory drivers, cdrom image support, benchmark packs... and, ultimately, games).

Once MTCP is running, then I use FTPSRV to load the curated set of games onto the drive - this is a pretty big collection that I have unpacked and use within Dosbox on my workstation, and copy to the real DOS machines to match the layout; it's around 60GB in total, though I usually do a 'genre' folder at a time (RPG, FPS, SIM, etc). This way I know that everything is there, installed correctly and ready to go.

10Base-T (good riddance to 10Base2 - coax, bnc connectors, t-pieces and all!) is fine for pushing config files and utilities around... but when you are dealing with ISO images (as is the case with many late DOS games) it just becomes really unwieldy.

On some models it's relatively easy to simply pull out a drive caddy and connect the laptop drive up to a USB dongle and access directly in Linux for bulk data transfer, but some of these machines are particularly fragile (I had the IDE caddy flat ribbon cable on a Toshiba Tecra 550CDT disintegrate the first time I removed the disk, leaving it unusable) or are not easily accessible. On pre-Pentium machines (not just laptops) I tend to use CF based drives instead, and of course that's a far easier method to do bulk transfers.

I don't necessarily need gigabit transfers... but the fact that the gigabit ethernet interface in this particular laptop seems to only be capable of downloading at no faster than 1 Megabyte/sec (whilst simultaneously uploading at a much more realistic 10 Megabytes/sec) is just .... odd, and makes doing the bulk data downloads impractical.

DaveDDS wrote on 2025-09-11, 15:12:

Which makes me curious... what are you doing that needs gigabit transfers in DOS and a couple megs/second isn't enough?

For DOS machines, I don't really need more than 100 Mbps.
However, at certain point, 1 Gbps became integrated on motherboards.

On my test machine - in DOS - I've seen 11 MB/s with a 100 Mbps NIC, so I'm a little disappointed to see only 5-7 MB/s with a 1 Gbps one, and I would definitely suspect some defect/misconfiguration if I saw only 1 MB/s.

I would agree that in almost all cases a 100Mbps NIC is as fast as needed... and if I could achieve that I would be happy. Due to the nature of DOS I would never expect to achieve more than a fraction of GigE speeds, but only 1%? That's just bad.

^@DaveDDS Thank you for sharing your memories! ^^
Personally, I grew up with an 8-Bit computer that had 1200 Baud datasette (Sharp MZ).
However, when I got my 286 PC, I saw the speed difference between floppy controller (500 KBits/s), CD-ROM (1x, 150 KB/s) and data/fax modems (1,8 KB/s for 14k4).

In that relationship, even early 2000s "broadband" internet with 150KBit/s, 500KBit/s and 1 MBit/s felt very backwards, if you consider that an 1987 NE2000 card could do 10 MBit/s in principle.
Even ISA/AT bus from 1984 was up to that.

I wasn't thinking that way in retrospect, by the way. I felt same in early 2000s already:
Back in 2000s, I always divided these Bit speeds by 8 and wondered where all the progress is supposed to happen.

Here where I live, we almost would have had fibre connection in the 1970s.
If it wasn't for political intervention that hindered it (cable TV got all the money for infrastructure).