See the later parts of this thread for context: Re: mTCP NetDrive: network attached storage for DOS 2.0 or better

In short, there was some discussion about MS Lanman vs. NetDrive when reading an ISO using SHSUCDX. When using Lanman or NetDrive directly to read the ISO file the performance is the same. But when adding SHSUCDHD+SUSUCDX to create a new drive letter to see inside of the ISO, NetDrive was far slower. Which doesn't make sense because SHSUCDHD+SUSUCDX don't add much overhead.

I ran my own benchmarks and I found there to be no real performance cost when adding SHSUCDHD+SUSUCDX

Machine: 386DX-40, Davicom 16 bit ISA Ethernet card, DOS 5.02

Test setup:

• Take a 330MB ISO (JRNEWSLE.ISO) and wrap it inside of another ISO (ISO.ISO).
• Stick that on a large NetDrive image and mount it.
• Time copying the file (ISO.ISO) to nul:
• Use SHSUCDHD+SUSUCDX to mount ISO.ISO, exposing JRNEWSLE.ISO.
• Time copying JRNEWSLE.ISO file to nul:

To do a good benchmark I just want to do a file copy of a large file. Copying the wrapped ISO on the NetDrive drive letter does that. Using SHSUCDHD+SUSUCDX to expose the ISO within allows me to do that again. There is less than a 1MB difference between the inner ISO and the outer one, so it's comparable, and I normalize to KB/sec read. Also by doing streaming read the benefit of any caching is thrown away.

Results:

• Copying ISO.ISO (which contains JRNEWSLE.ISO) to nul: 884 seconds to copy 332544KB, or 376KB/sec.
• Copying JRNEWSLE.ISO from within ISO.ISO using SHSUCDHD+SUSUCDX to nul: 890 seconds to copy 331960KB, or 372KB/sec.
• There were no dropped UDP packets during the tests.

That shows there is no extra significant overhead when using SHSUCDHD+SUSUCDX on an ISO hosted by mTCP NetDrive.

In the other thread where things go badly RAR is used to read a large RAR file. It really should not make a difference unless RAR has a pathological access pattern, which I doubt is the case.

If the other machine is getting dropped packets that could make a huge difference; NetDrive will wait 2 seconds before doing a retry because it can be used across the internet, while SMB might be doing retries faster because it should be all local traffic. If the network is noisy and dropping packets that would make a difference, but it should look the same both with SHSUCDHD+SUSUCDX and without it.

Behavior in VirtualBox was the same, except far faster ...