Not sure if the Seth Simon from here would be any better
https://www.packetdriversdos.net/

https://www.ibiblio.org/pub/micro/pc-stuff/fr … et/e100pkt/0.3/

Matth79 wrote on 2026-06-10, 17:13:

Not sure if the Seth Simon from here would be any better

Only marginally better...

download to NUL: 9042
download to HDD: 214

Grzyb wrote on 2026-06-10, 15:29:

native PD:

download to NUL: 8877
download to HDD: 193 !!!

While I haven't yet debugged the .com file, if there is a so large difference between downloading to NUL and to the HDD it usually means that there are no/little buffering of writes to the disk, which means that the HDD has to write each byte or small group of bytes separately, needing to seek the proper track and position again.

EDIT: If you wish to check if this is the issue, MS-DOS 6.22 comes with RAMDRIVE.SYS, allocate a disk in memory to try, if this is the case that will significantly increase the performance.

Currently using the PD by Seth Simon.
Download to RAMdisk is fine - same speed as to NUL.

BTW: RAMDRIVE.SYS is limited to 32 MB - what's the recommended replacement?
And why does "ramdrive.sys /e" in MS-DOS 7.10 require "device=c:\windows\himem.sys" in CONFIG.SYS? In this DOS, HIMEM.SYS is loaded automatically!

Grzyb wrote on 2026-06-11, 10:47:

BTW: RAMDRIVE.SYS is limited to 32 MB - what's the recommended replacement?

Try XMSDSK.

It can create RAM drives up to 2 GB.

Joseph_Joestar wrote on 2026-06-11, 10:59:

Try XMSDSK.

Thanks, seems to work fine!

Meanwhile, testing with another client - FTP2P...

download to RAMdisk: 11224
download to HDD: 217

Unrelated to packet driver testing, but just random trivia:

Xmsdsk hosted ramdisks can be used with the drvspace driver. You just need to have the drvspace.000 file present on the ramdisk, then point scandisk at it with the undocumented /mount argument. Scandisk will mount it for you silently.

1gb is the max officially supported size though.
if you have 64kb of upper memory to just blow (drvspace.sys /move in config.sys will relocate it to umb instead of dos memory), it can be useful. A whole volume can be ftp'd then mounted this way.

Derail over--
Carry on!

I had problems with ne2000 packet drivers on my 486, which disappeared when I disabled both the processor and the external caches. It's weird, I don't know why it worked...

Grzyb wrote on 2026-06-11, 12:49:

Thanks, seems to work fine! […]
Show full quote

Joseph_Joestar wrote on 2026-06-11, 10:59:

Try XMSDSK.

Thanks, seems to work fine!

Meanwhile, testing with another client - FTP2P...

download to RAMdisk: 11224
download to HDD: 217

Hmm it seems that FTP2P is another client that doesn't do proper buffering of data before writing to disk.

As an alternative to RAMDRIVE.SYS or XMSDSK you might also try it with SMARTDRV with write-behind cache enabled: SMARTDRV <drive letter>+ <other parameters...>

The "+" after the drive letter tells SMARTDRV to enable write-behind caching of the given drive, so unless if the given client bypasses DOS File Write interrupts/functions it will be cached by SMARTDRV instead of directly written to the disk, it also has the advantage that you don't have to copy the file from the RAM disk to permanent storage after transfer, however there is a big disadvantage to this method, whenever shutting down the machine you need to run SMARTDRV /C to make sure that the caches are flushed so data doesn't get stuck half written(And crashes are also more likely to result in lost data).

Using the PD by Seth Simon, and mTCP FTP...

smartdrv c+

download to HDD: 286

Seriously, can't suspect the FTP clients - both work fine with both NDIS and ODI, even without SMARTDRV.
There's something wrong with the Packet Drivers, but I can't even imagine what exactly...