It should be noted that NDIS/ODI shims don't slow things down a lot.

I've connected my 100 Mbps NIC again, and the results are:

native PD: 10972 KB/s
ODI+ODIPKT: 10279 KB/s

I'm never going to insist on gigabit speeds for DOS networking code, but if something smells broken I'd like to try to find out why because it might point to a flow control problem that can be fixed in software.

For your inspiration: https://yeokhengmeng.com/2024/08/dos-on-thinkpad-x13-gen1/

mbbrutman wrote on 2025-09-11, 16:35:

For your inspiration: https://yeokhengmeng.com/2024/08/dos-on-thinkpad-x13-gen1/

I've actually got a couple of later laptops (including a T440) that would probably work really well, but the issue is one of screen aspect ratio; 4:3/5:4 screens just sort of fizzled out around the introduction of the Intel Core series. They're really tricky to find - it's mainly the corporate brands and models that stuck with them for any length of time.

I've just tried my 1 Gbps NIC with Microsoft Network Client for MS-DOS...

using the latest NDIS2 driver
"copy /b testfile nul" speed is 2380 KB/s

So there's nothing wrong with mTCP FTP client when it achieves 5-7 MB/s.
The problem is in Broadcom's DOS drivers.

I've a few PCMCIA network cards that I can try in this thing (both cardbus and non).

If I can figure out the right PC card services I think that's the next avenue. I'm positive I've had 4-5 megabyes/sec even from a non-cardbus 10/100 pc card before using MTCP, which is why the performance of this broadcom stuff is so disappointing.

There's another version of the Broadcom (B57) NDIS/ODI driver at (https://packetdriversdos.net/).

It dates itself from 2011 (110802), and reports version 15 (15.0.1), so quite a bit later than any of the B57.COM drivers looked at so far. It's 64,575 bytes, so a good 8-10 kbytes bigger than the earlier versions.

Upload speeds using it seem to float around 13 Megabytes/sec, so it looks to be an improvement on the versions I've tried so far, in that direction at least. Though downloads are still a miserable 1.2 Megabytes/sec - I am beginning to think this is a hardware problem with the machine.

Not a great deal of luck on the PCMCIA front. There are card services drivers available from IBM/Lenovo (https://support.lenovo.com/gb/en/downloads/migr-4kk4xu), and these do support (amongst others) the T43, but... I can't get much working with them.

Of the following cards:

DLink DFE670 (non-cardbus 10/100) - uses DFE670PD.COM, a normal DOS packet driver
DLink DFE690 (cardbus 10/100) - uses DLKRCB.COM, a normal DOS packet driver
3Com 3CXFE575CT (cardbus 10/100) - uses ELPC575.COM, an ODI/Netware driver

I can only get the DFE670 packet driver to detect the card. Both cardbus cards do not get detected by the drivers, which leads me to suspect that the card services are only enabling the interface in PCMCIA mode, and not in Cardbus mode (it is a Cardbus port). I've also got a couple of Xircom 10/100/modem cards (both cardbus and non-cardbus), but they're Type III thickness, which don't fit - this is a real shame as I've had good experiences with these in the past (uses the CBEPD.COM packet driver).

The DLink DFE670 gets a lousy 920 kbytes down and 800 kbytes up, so it's a fairly rubbish implementation. I think I tried that particular card on a number of machines in the past and it sucks equally on all of them.

Rebooted from a Linux live cd and the cardbus cards do in fact work perfectly. Both the DFE690 and the 3CXFE575CT happily max out at their 100mbit speeds. So it's clearly a limitation of the IBM/Lenovo DOS card services that is only activated in in PCMCIA mode, not Cardbus.

The crappy DFE670 sucks just about the same.

Running "wget -O /dev/null ftp://server/bigfile" shows a rock solid transfer rate of 11.2 Megabytes/sec for both cards. I suppose, therefore, that I could re-image the drive with a small Linux partition and just reboot to a text-mode Debian environment if I wanted to do any bulk data transfer.

Oh dear, there's even NDIS2 driver from 2013 - seriously, DOS is immortal!

Anyway, I've quickly tried the NDIS from 2013, and the ODI from 2011 - no change, FTP download is still circa 5 MB/s.

It really is insane how long it held on!

I also remember what an upgrade 10Mbps half duplex was over serial/parallel cables.

If you don't get throughput over a link and something is not bottlenecked (cpu or io) on either side, it is probably tcp window tuning.

Look at it this way: with a ping of 1ms, you can send 1000 packets per second if you send-ack-send-ack with only one packet in flight. Since a packet is 1500 bytes, the most you can get over a gigabit link this way is just under 1.5 megabytes per second. To send faster, you have to have more than one packet in flight, therefore a bigger tcp window.

Modern ip stacks do automatic window size tuning and rate throttling around a working point that it automatically tunes for round trip time and packet loss, in a way that just seems to work. This was definitely not the case in the dos/win9x days.

Edit: seems as if I missed page 2, I referred to Dave's post about his first experiences with networking.

Broadcom nics are some of the best I have worked with. Really impressive performance. In a HP proliant microserver (N36 1.3 dual core version) the onboard gigabit broadcom manages 119MB/s on linux with the tg3 driver, without pegging the cpu. That's just about wire speed. An intel gigabit pci express card in the same machine does just over 100MB/s with e1000e driver.

st31276a wrote on 2025-09-12, 06:11:

Broadcom nics are some of the best I have worked with. Really impressive performance. In a HP proliant microserver (N36 1.3 dual core version) the onboard gigabit broadcom manages 119MB/s on linux with the tg3 driver, without pegging the cpu. That's just about wire speed. An intel gigabit pci express card in the same machine does just over 100MB/s with e1000e driver.

I have exactly the same experience under Linux. For many years HP used Broadcom NetXtreme II/III in their DL-series servers and we never had an issue.

I'll say again... I think, based on the evidence in this thread, that there is some sort of hardware/firmware/driver problem with the Broadcom NIC in this laptop. Terrible speeds in DOS, and the Linux driver refuses to recognise it.

On balance, the way forward seems to install a mini Linux partition (maybe 1-2gb) and reboot to that, using one of my cardbus 10/100 pc cards instead (if I could pick up a cardbus gig NIC for a few pennies, even better).

megatron-uk wrote on 2025-09-12, 07:13:

I have exactly the same experience under Linux. For many years HP used Broadcom NetXtreme II/III in their DL-series servers and […]
Show full quote

st31276a wrote on 2025-09-12, 06:11:

Broadcom nics are some of the best I have worked with. Really impressive performance. In a HP proliant microserver (N36 1.3 dual core version) the onboard gigabit broadcom manages 119MB/s on linux with the tg3 driver, without pegging the cpu. That's just about wire speed. An intel gigabit pci express card in the same machine does just over 100MB/s with e1000e driver.

I have exactly the same experience under Linux. For many years HP used Broadcom NetXtreme II/III in their DL-series servers and we never had an issue.

I'll say again... I think, based on the evidence in this thread, that there is some sort of hardware/firmware/driver problem with the Broadcom NIC in this laptop. Terrible speeds in DOS, and the Linux driver refuses to recognise it.

On balance, the way forward seems to install a mini Linux partition (maybe 1-2gb) and reboot to that, using one of my cardbus 10/100 pc cards instead (if I could pick up a cardbus gig NIC for a few pennies, even better).

Another potential option might be to find a Cardbus Gigabit NIC that has NDIS3 drivers and run Windows 3.11 from DOS or, if you don't mind DOS 7.x , maybe even use Windows 9x (with bootgui set to 0 in msdos.sys ), for which native Gigabit cardbus drivers are more likely to exist.

EDIT: TP-Link TG-5269 might be based on the Realtek RTL8169SC chipset. Maybe that would work better either through NDIS2 in DOS or NDIS 4.0 or newer under Windows 9.x (no NDIS3 drivers for that one, AFAIK).

I've just removed the ~118GB extended/logical D: partition on the drive and sliced out 8GB of it for Linux. Disk now looks as follows:

2GB FAT16 (Win98SE DOS install) (C:)
8GB Debian Linux
~110GB FAT32 (Games drive) (D:)

Debian has most services disabled and no X server, and boots to a shell with vsftpd running with TLS/SSL - 22 seconds to get to a login prompt (not bad for an old 2.5" IDE drive). PCMCIA services are running and it autodetects whichever card I've got inserted. The DOS partitions are mounted at /dos and /games and downloads to them work at wirespeed using FIlezilla from my desktop. That's about as good as it can get for 10/100 cards. Grub has DOS set to boot by default, so only when I need to do transfers do I need to choose a different boot option.

There's definitely something wrong with the Broadcom NIC/firmware, as the kernel complains every time it boots about not being able to get a MAC address.

darry wrote on 2025-09-12, 08:23:

EDIT: TP-Link TG-5269 might be based on the Realtek RTL8169SC chipset. Maybe that would work better either through NDIS2 in DOS or NDIS 4.0 or newer under Windows 9.x (no NDIS3 drivers for that one, AFAIK).

I just found a DLink DGE-660TD cardbus/GigE card new-in-box for just over £10 including shipping. I'll give that a go; what I've got working now is absolutely usable, and I'd be happy with it if I can't get a gigabit pc card working.

The main limitation now will be the 2.5" IDE speeds - it's an ATA100 drive connected to the onboard SATA (1) controller via a bridge chip (don't ask why IBM did that... but they did, and it makes using another bridged device, like a IDE->mSATA converter virtually impossible). hdparm under Debian reports the drive as having a ~58 Megabyte/sec read rate from cache... no slouch for a 2.5" IDE, but a long way from being able to sustain a gigabit link.

megatron-uk wrote on 2025-09-11, 12:42:

It's on the Lenovo support page here: https://support.lenovo.com/co/en/downloads/ds002857 […]
Show full quote

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:

The attachment b57_2007.jpg is no longer available

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?

If it is actually using the FF:FF:FF:FF:FF:FF as a mac adres then yes, that is a problem.
Could be that some small eeprom got corrupted or died, tends to be a tiny 1,2k or 4k eeprom.
Though in some cases, I think, it's the computers main bios that should load the information to the nic chip.

The linux tg3 driver not loading could be related to this issue.

There's some "Userdiag" software shipped with Broadcom's drivers - perhaps it can tell something interesting?

Just grabbed a copy of that from the Lenovo .iso image... yep, the NVRAM/EPROM is busted:

The only thing I can think of is to reflash the IBM platform and BIOS images again.

There's a load of EPROM/NVRAM/Firmware programming commands in the B57UDIAG.EXE tool, so it looks like there could possibly be a way to restore things.

But, there's no help text, readme file or any sort of instructions. Also no indication if any of the files are actual firmware, or executable code for the NIC. Just one EXE, a load of .BIN files and a couple of TXT files containing MAC addresses and what appears to be a summary of EPROM values from another card (a BCM5701).

Aha....

B57UDIAG Users Guide

https://www.alliedtelesis.com/sites/default/f … /2711fx_dug.pdf

Looks like a combination of the "-firmall", "-updateasfcfg" and "-updatesecfg" could potentially put the NIC in a working state and rewrite the necessary config data... but, it needs a copy of eeprom.bin for the specific device type (BCM5751) in this case.

just an FYI, the mac address will likely never be in any file you can download, though some other one might be.
It should be written somewhere on the laptop, on a sticker, somewhere and either you can set it using some software or you'll have to edit it in one of the files to flash.

edit: the -updatesecfg seems to me, to be the one to try first... given a good eeprom file...