I spent two long days coding streaming writes for mTCP NetDrive. I have some early results.
The test: Copy a large file (1.7MB) from a 386-40 with an NE2000 card to a Linux server about 1800 miles away.
Old code: 18KB/sec
New code: 214KB/sec
The new code is about 350 bytes larger and uses no additional memory on the client side. On the server side I just had to increase buffer sizes.
And DOS is none the wiser .. the remote server just looks like a drive letter.
@wbpeckham You probably already know this, but DOS didn't start with networking so everything is grafted on.
I'm a big fan of the "packet driver" approach, which loads a small device driver for your card as a TSR and enables the higher level applications using a published API.
Besides the packet driver, my code needs one-time configuration. After that run EXEs for what you need. That's pretty simple.
Greetings fans of DOS networking! I'm working on bug fixes for mTCP. If you have a bug report or a feature request now would be a great time to let me know. Send it by email or ping me here.
So far I've done a lot of "code golfing" (making things smaller and faster). Telnet will have SIXEL graphics enabled and a few bug fixes. TCP has a flow control improvement to help with the occasional stall. And there are a few other small fixes so far too.
Here is some potatovision proof of the AUI-hacked Farallon EtherMac AAUI #Ethernet MAU mentioned in this post working with #mTCP on an IBM PC/AT (with some help from an old Netgear twisted pair to WiFi adapter).
What I haven't done yet is verify that the AAUI connector still works, but I'd bet it does: all of its wires just pass through the board directly to the MAU.
For any #MTCP, #DOS and #Retrocomputing nerds out there who are also running httpserv and want pretty graphs, poke me for a recipe for a hideosly bloated #logstash configuration to ingest the UDP logs.
I feed it to #Graylog which stores the data in #Opensearch - a pipeline that combined (and this is accurate) needs, conservatively, 4096 times as much RAM as the floppy museum itself (8MB).
And while looking at this when making this screenshot: I wonder why someone would hit http//floppy.museum with a Referer-header indicating they come from a salesforce-dot-com address? http-colon-slashslash-136.146.46.127 (about halfway down the list).
mTCP NetDrive users ... the read-ahead version is ready for testing. I'm looking for your feedback on how well it works in your environment. See the announcement here for download links: https://groups.google.com/g/mtcp/c/ktDzPuWd1xw (no sign-in required)
Next up ... I know how I'm going to make writes faster too. With just a little more code in the driver.
NetDrive with read-ahead caching, running on a VM to a local server and to a server 50ms away. A 4KB read-ahead cache results in a 3x speedup locally and nearly a 5x speedup on the remote server.
Real hardware results depend on the speed of the hardware. Slow machines don't benefit much when connected to local servers, but they still get the full benefit on remote connections.
And this is where real hardware asserts itself ...
Using a 4KB read-ahead cache on the DOS side in a VM gave a 5x speedup, which was great and expected; you ask for 1KB and you get 4KB more without having to wait a full round trip.
But the PCjr said no. After a week of cleaning up the code and gathering stats I understand the problem better; it's just processing packets as fast as it can. The best speed-up on that specific test is 30%, which isn't bad, but not 5x.
I haven't touched NetDrive in a while so I got motivated and just spent two hours adding a 1 sector read ahead cache into the code. After a read request the server sends one extra block, and the DOS side caches it. On the next read the DOS side checks the cache.
Running CHKDSK against a 200MB drive across the network to a server that is 47 milliseconds away was taking around 26.8 seconds. Now it takes 17.69 seconds.
Yep, this feature is worth doing ...
mbbrutman
Tom Stepleton
Ltning
ltning