I managed to figure out the issue with the ODI driver: My net.cfg file that I put in the same folder as the driver was formatted incorrectly, it needed a tabbed space for the "Frame Ethernet_II" line as well as adding a "Link support" section. The relevant net.cfg is attached to this post.

Unfortunately the performance under mTCP is poor and inconsistent. I get maybe 5 Mbps rather than 20Mbps with the native driver on the RTL8139D.

Additionally, a friend on Discord sent me the file at this link (RTGPKT.COM) which is apparently a native packet driver for the RTL8169SC, but it just locks up on my system when I run "RTGPKT.COM 0x60" without any success. Wondering if anyone knows how to get it working...

eton975 wrote on 2026-08-05, 19:39:

Unfortunately the performance under mTCP is poor and inconsistent. I get maybe 5 Mbps rather than 20Mbps with the native driver on the RTL8139D.

How are you measuring the speed?

Anyway, a few hints:
- add "MTU 1500" to the MTCPCFG file
- try to increase "buffers 8 1600" to "buffers 16 1600" in NET.CFG
- try to replace the ODI+ODIPKT drivers with NDIS+DIS_PKT, see for example the attachment in this post - Quality of packet drivers: Intel

Grzyb wrote on 2026-08-05, 21:15:

How are you measuring the speed? […]
Show full quote

eton975 wrote on 2026-08-05, 19:39:

Unfortunately the performance under mTCP is poor and inconsistent. I get maybe 5 Mbps rather than 20Mbps with the native driver on the RTL8139D.

How are you measuring the speed?

Anyway, a few hints:
- add "MTU 1500" to the MTCPCFG file
- try to increase "buffers 8 1600" to "buffers 16 1600" in NET.CFG
- try to replace the ODI+ODIPKT drivers with NDIS+DIS_PKT, see for example the attachment in this post - Quality of packet drivers: Intel

I was mostly eyeballing the speed, but I did take a look at the output after the file transfer ended and it was about 300KB/sec.

I managed to get the native RTGPKT.COM packet driver working after a lot of fiddling around. Had to put the TG-3269 card in the 2nd to bottom PCI slot, remove all other network cards and disable serial port #2. I think this was some sort of IRQ or resource hogging conflict on PCI IRQ 11. After this it seems to work both in Win98SE proper and in MS-DOS 7.10. Additionally, to get decent speed I had to force 100MBit mode instead of 1Gbit/auto-negotiation mode by running "RTGPKT 0x60 -m 100full".

I may try your suggestions with the ODI and NDIS shims but I am happy to have finally gotten that rare native packet driver working with this cheap Gigabit card. Thanks

I have also attached the RTGPKT files below in case the link above dies.

eton975 wrote on Yesterday, 00:53:

I was mostly eyeballing the speed, but I did take a look at the output after the file transfer ended and it was about 300KB/sec.

I meant what program you were using - mTCP FTP client? mTCP FTP server? Something else?
Downloading to NUL, HDD, or some other device?

From what I recall, a similar card - RTL8169S-32 - worked very well with mTCP, achieving speeds much better than theoretical maximum of 100 Mbps Ethernet.

Grzyb wrote on Yesterday, 03:01:

I meant what program you were using - mTCP FTP client? mTCP FTP server? Something else? Downloading to NUL, HDD, or some other d […]
Show full quote

eton975 wrote on Yesterday, 00:53:

I was mostly eyeballing the speed, but I did take a look at the output after the file transfer ended and it was about 300KB/sec.

I meant what program you were using - mTCP FTP client? mTCP FTP server? Something else?
Downloading to NUL, HDD, or some other device?

From what I recall, a similar card - RTL8169S-32 - worked very well with mTCP, achieving speeds much better than theoretical maximum of 100 Mbps Ethernet.

mTCP FTP client on the P3 Tualatin system, downloading from Golden FTP Server v5.00 on Windows 10 Pro x64, server using RTL8111E PCIe NIC.

Downloading to HDD (Seagate Barracuda ATA IV 40GB IDE)

Try also downloading to NUL.

If download to NUL speed is OK, but download to HDD is abnormally slow, then it can be improved by finding the optimal combination of FTP_TCP_BUFFER and FTP_FILE_BUFFER settings.

Grzyb wrote on Yesterday, 03:16:

Try also downloading to NUL.

If download to NUL speed is OK, but download to HDD is abnormally slow, then it can be improved by finding the optimal combination of FTP_TCP_BUFFER and FTP_FILE_BUFFER settings.

I piped an example file of about 20MB to NUL with "get <filename> NUL" and it was indeed about 4 times as fast as compared to the HDD. So I will try what you said.

eton975 wrote on Yesterday, 03:25:

I piped an example file of about 20MB to NUL with "get <filename> NUL" and it was indeed about 4 times as fast as compared to the HDD. So I will try what you said.

What numbers exactly?

With such hardware, I would expect like 5 MB/s to HDD, and 20 MB/s to NUL - so the 4-times difference can be perfectly normal.

Grzyb wrote on Yesterday, 03:51:

eton975 wrote on Yesterday, 03:25:

I piped an example file of about 20MB to NUL with "get <filename> NUL" and it was indeed about 4 times as fast as compared to the HDD. So I will try what you said.

What numbers exactly?

With such hardware, I would expect like 5 MB/s to HDD, and 20 MB/s to NUL - so the 4-times difference can be perfectly normal.

Using the native RTGPKT.COM with -m 100full for 100Mbits/s full-duplex operation:
1181KB/s with HDD
4955KB/s with NUL

Using the ODI shim:
491KB/s with HDD
351KB/s with NUL (yes, slower than HDD!)

Using RTGPKT.COM with IDE Block mode and DMA modes set to "Auto" in BIOS utility, plus XHDD in config.sys with "DEVICE=XHDD.SYS /H /S20 /O":
4042KB/s with HDD
5746 KB/s with NUL

ODI results are suspiciously slow - have you tried "buffers 16 1600"?

Try also NDIS driver with DIS_PKT.DOS shim.

4 MB/s to HDD, however, looks OK.

I have a P3 800 MHz machine, and RTL8169S-32, may try them later...