mTCP NetDrive with read-ahead caching (test code)

[Michael Brutman]

If you are interested, I have added a read-ahead cache to NetDrive that can speed reads up.  Depending on your machine speed and server distance it can be as much as 5x faster, with just a 4KB read-ahead cache.  Remote connections see the best improvement, but even faster DOS machines on a local network will see good improvement.

I'm looking to get some feedback on the new feature - how easy it is to use, and what kind of speed-ups you might get.  It requires new binaries on the server and client side, which can be found here:

• http://www.brutman.com/mTCP/download/mTCP_NetDrive_2025-04-28_DOS.zip
• http://www.brutman.com/mTCP/download/mTCP_NetDrive_server-bin_2025-04-28.zip

Most people probably don't have a remote server to test against so I have updated the one at brutman.com (port 2002) with the new code.  So if you have the new device driver, you can test against that to see what kind of speedup you get.  In theory you can get up to a 5x speedup if you are slightly distant from it.

For measuring the speedup use the new ND_CAHE.EXE program, which is included in the DOS download.

Let me know how it works for you!

Thanks in advance,

Mike

[Michael Brutman]

Tonight I tested this code on my faster Pentium 133 system and it was randomly returning bad data on reads with the read-ahead cache enabled.  I'm kind of surprised because if this was a timing problem it would have happened on the virtual machines I use for testing.

For now please don't use this code, or use it with caution.  I might have a machine specific problem with the packet driver, but it shouldn't be happening.  It doesn't happen on my other machines or in virtual machines but I intend to find out what it causing the problem.

[Michael Brutman]

I have found and fixed the bug; I did not disable interrupts while DOS was copying data from the cached read-ahead blocks, and newly arriving read-ahead blocks were arriving at the same time, stepping on what was being copied from the cache.

It was very timing specific but still I should have seen this.  I normally test on a virtual machine and move to real hardware afterwards.  The virtual machine is basically infinitely fast, so it should expose timing problems, and then the PCjr is as slow as it gets, so it should also expose timing problems.  A Pentium 133 exposed the timing problems in this case.

I'll post updated versions after I get more testing time on the code.  Also, I've started sketching out how to make writes faster too, but that's a few months away before it is safe to share.

-Mike