mbbrutman wrote on 2026-01-13, 01:20:

The read-ahead function will eventually get out; it just makes more sense now to do the same for writes too before I release it. Depending on the machine and the distance to the server it increased the speed by 5x, which is something I need/want for usage with public servers.

There is also plenty of other work to be done too, but I'm having problems finding the time to get to all of it. But rest assured, it's not dead.

That's good to hear! I know how hard it can be to find time for side projects .

I really appreciate the work you've put in to create the mTCP package, it's something I use on all my retro computers.

(Delayed response - recovering from the flu)

Thank you ... and if it isn't obvious, I appreciate what you and the whole team here do at Vogons ...

Thanks for your Netdrive!

I have a Toshiba Satellite Pro M10, but last year, I physically broke the HDD IDE connector. Thanks to Netdrive, it gave a second life to this computer. Yesterday, I installed Windows 98 completely diskless on it. I've made a small pxelinux boot drive of 7mb). I started the first part of the Windows install on virtual box with 2 hdd images, then I transferred the small image to pxeboot (boot drive), and the larger one (Windows drive) is used by netdrive. To my surprise, Windows 98 is fully working, stable, and much faster than anticipated. I tested Diablo. and It is very playable, with just a few audio glitches. I also tested Warcraft II, it seems to work without any issues. As for cd-rom drive, I used the Dos driver as a workaround. The internal Ethernet car is used for pxe boot and Netdrive. I use a pcmcia network card for Win98 network. I'm very pleased overall.

The only thing is that I need to kill the session on the server side between reboots.

Here is a glimpse into the future - I implemented streaming writes:

Machine: 386-40, 16 bit NE2000 card, DOS 5.
Test: Copy a 4MB file to a server that is 55ms away. (About 1400 miles.)

• Old code: 220 sec, 18.6KB/sec
• New: 17.14 secs, 238KB/sec.

(Copying the file to the same local IDE hard drive takes 4.84 seconds so the remote copy to a server is only 3.5x slower.)

The new code requires about 650 more bytes of memory; 350 for code and 300 for buffer. I think the performance bump is well worth it. Read speeds haven't changed, but I'm going to work on that next.

I'm not sure if people missed it because I started a new thread, but I'll repost it here in case was overlooked:

About a year ago I started experimenting with how to make NetDrive faster. I have the next revision of that experiment available for testing, and I am excited by the results. The new code was 1.4 to 2.7x faster when talking to a server on the same network, and 12x to 21x faster when talking to a remote machine across the internet.

I'd like to get some help testing it though. It is rock solid, and I'm not concerned about data corruption. I'd just like to hear what kind of improvements other people see on their machines. The new code requires both the DOS and server side be updated. The downloads are at:

• https://www.brutman.com/mTCP/download/mTCP_Ne … 6-04-09_DOS.zip
• https://www.brutman.com/mTCP/download/mTCP_Ne … _2026-04-09.zip

Some quick notes:

• You must update to the new server to test this code. (Your DOS machines using older code can use the new servers; if they can't that is a bug.)
• Slower machines do not see as much of a benefit, as they can barely keep up packet processing. But even an XT connecting to a remote server saw more than 2x improvement when reading and more than a 3x improvement when writing.
• I need your feedback before I go further and make this widely available.

Thanks,
Mike

Very exciting!

What kind of machines have you already done testing on? I mainly use NetDrive on my 286 and 386s.

Also any type of test scenario/application we should use to get comparable results?

The quick answer:

• My 386-40 connected to a local server went from reading 373KB/sec to 779KB/sec for a 4KB read, and 882KB/sec for an 8KB read.
• The same machine connected to a server with a 50ms round trip went from 18.8KB/sec to 90KB/sec for a 4KB read, and 151KB/sec for an 8KB read.

• An XT with a WD 8003 card connected to a local server went from reading 60KB/sec to 75.3/sec for a 4KB read.
• The same machine connected to a server with a 50ms round trip went from 14.8KB/sec to 42KB/sec for a 4KB read.
• 8KB reads failed with an excessive number of retries - the network card and CPU are just not fast enough to work with read-ahead.

The longer answer - there are three key factors here - machine speed, distance, and I/O size.

• Small I/Os (1KB or less) will see no improvement. At 1KB or less the behavior is the same as it is today.
• Slow machines don't get as much speed-up, as they have limited buffers on the network card and are often not fast enough to keep up.
• Local connections will see some speed-up, but not as much as remote connections because there is less opportunity.

The changes work by doing more work while waiting for the server to respond, so the opportunity is greater with distant servers. But as you can see above, even with a 1ms round trip time to the server there is still plenty of gain.

Slower machines don't do as well - they literally can't keep up and they start to drop packets quickly. But even an XT class machine saw

I did some more benchmarking today. The results are in a Google sheet: https://docs.google.com/spreadsheets/d/1cXfR- … dit?usp=sharing

These numbers are slightly different because the benchmark is different. These numbers include filesystem overhead for DOS, so they should be marginally lower than the first numbers which tried to eliminate that overhead.

The test machines include an 8088 class machine, a 386-40, a 486-66 and a Pentium 133. I need to cobble together a 286 to round out the set. The P133 has a 100Mb/sec PCI card on it; try not to giggle when you see the numbers.

While I was defragmenting drive I (the first NetDrive attached hard disk image) using Speed Disk, defragmentation of the entire drive was slow. It took anywhere from two to four seconds just to read, write and verify clusters. Then I used parameters that are needed to connect the network attached drive - -mra and -mws to 4 KB respectively to improve performance.

Hopefully, the next time I defrag the NetDrive attached hard disk, lowering the read-ahead and write-ahead to 4 KB should help improve performance. 😀

What CPU and network card are you using?

Limiting the read-ahead to 4KB should only be necessary on an old card or a slow CPU. Generally bigger is better unless bigger means the server is flooding the DOS machine and causing packet drops.

mbbrutman wrote on 2026-04-16, 02:13:

What CPU and network card are you using?

Limiting the read-ahead to 4KB should only be necessary on an old card or a slow CPU. Generally bigger is better unless bigger means the server is flooding the DOS machine and causing packet drops.

I'm currently emulating a Gigabyte GA-486GL under 86Box right now - the speed is set to 25 MHz (Intel 80486)...so, 4 KB read-ahead is definitely necessary. The emulated network card that I'm using is a Novell NE1000.

I mean, flooding a server and causing packet drops is definitely not a good thing.

Ok, well, you are on an emulator so all bets are off. Even my 386-40 can use 32KB of read-ahead. And the NE1000 is a pretty limited card; try emulating something better.

I'll see if I can switch to the NE2000 to see if performance has improved or not. :\

You are running in a emulator. It might improve, but I wouldn't worry about the performance of anything that is being emulated.

Knowing that it is working correctly is the most important part of the test code. People are reporting similar speed-ups to what is in my spreadsheet, which is just a bonus.

I wouldn't worry about it too. I really love how mTCP NetDrive imrpoved over the last 2+ years and I proud of that. 😀

I did some testing on my Olivetti M28 286 and I got significant worse performance with the new build with read-ahead compared to the previous one. I tried different cache sizes beside the default 8kb and larger ones made it worse. Reduced to 4kb and that improved things, but previous version still quicker. Perhaps 2kb would make a difference in improved performance. ND_CACHE benchmark testing just timed out. Network card is an 3COM Etherlink II. Using MS-DOS 3.1

I do run the server as a Docker container. I will retest on my 386 SX tonight to see if the issue can be replicated.

What network card?

If you are using an older, smaller network card then the read-ahead feature should be set to no more than 4K. The optimal setting is based on the actual card in use and the amount of activity on your network.

If your network is busy you will have to lower the read-ahead setting even more. Also remember, this feature was primary designed for long distance connections, not local connections. It helps with faster machines on a local network too, but it really shines when you are going to a server outside of your home.

My Olivetti M28 uses a 3COM Etherlink II.

On my Chicony LT5400 386 SX 16mhz nd_cache doesn't experience timeout. Read-ahead performance fell of a cliff after 4kb! It did increase from 62kb/s to 76kb/s when cache was active at 4kb, so got some performance increase on local network. Here I'm using an ethernet to parallell Accton Etherpocket SP network device which is slow by its design.

Can the cache levels be configured on boot somehow, as variables or must it be through nd_cache?

Beside that I'd consider to be more conservative on the default levels. They were too large on my two systems.

I can do some more tests on my Olivetti

The cache setting is a per-connection thing because it depends on the server you are connecting to. You can set it right on the same command line you use to do the connection. (Use the -mra flag, which stands for max-readahead.)

I use the following defaults, based on CPU class:

• 8086/8088 class: 4KB
• 80286 class: 8KB
• 80386 class: 16KB
• 80486 or better: 64KB

The defaults assume people have relatively balanced systems. In both of your cases you seem to have fairly limited cards compared to what the system can support, hence the "impedance" mismatch. I would expect a 16 bit card on both systems, while you have an 8 bit card and a parallel port adapter. For unbalanced systems like that you are always going to have to set lower values.

Side note: The parallel port adapters generally have generous buffer sizes because they are designed for that bottleneck, which is why you did not see time-outs. Another good example of this is a PCjr with a Xircom PE3, which has 32KB on board. That combination starts to get timeouts much later than it should because of the amount of buffering the Xircom is doing.