Thanks so much for the detailed analysis. It will let me here with two conclusions for me:

1. thanks for the feedback. Much appreciated
2. your 386dx results show me that I might have still some work to optimize. But at the end it might most probably not bypass the performance of smb via msclient on the 386sx. Therefor I will leave it for the moment being.

Again I’m not here to criticize or so - I really like your program a lot. At the end I might not get the results I was „dreaming“ of meaning full usage of the 10Mbit Ethernet power which might netto result in 600kb/s via strong CPUs.

But you’ll never know maybe I will rerun it again later on. I was somehow hoping that „very little overhead“ due to that layer 2 approach would give me lot performance boost compared to quite intensive smb protocol transfers on my 386sx.

Anyway I know there are a lot of other factors speaking for netdrive

I'm not concerned about criticism. But I do want to understand when people are having "a bad time" with the code in case there is a problem.

One more question - where is your SMB server running?

My default smb share runs on a quite low end openwrt router (netgear 6220) with a usb stick w/ ext4 connected

A router with a proper WiFi or Ethernet port running SMB is still going to be better than a $15 RaspPi (2.4GHz only) with a badly implemented USB or Ethernet port. SPI is probably the problem there. For an apples-to-apples comparison run SMB o the RaspPi and then compare to NetDrive or EtherDFS.

At this point try the WiFi on the RaspPi instead of the Ethernet; it will probably perform much better, and it will help EtherDFS too. You can also try a USB connected Ethernet adapter on the native USB port. Avoid the HAT, as that has to go through SPI.

Lastly, NetDrive is not "layer 2" .. it's IP and UDP so it's fully routable. That's not much of an advantage on a local network, but I really do like that routable feature which is why I designed it to use IP and UDP. EtherDFS is truly layer 2.

1. chapter: I agree
2. chapter: usb ethernet connect might be worth it. Remember that I can’t access my rasp via wifi from my 386. I also experienced that etherDFS isn’t routable and even can’t survive wifi to lan „conversion“
3. chapter: of course true my fault

I'm confused about point 2 though ... Your RaspPi on Wifi is connected to a router and the 386 is connected to the router, right? At least NetDrive will work in that setup because it is routable. It's just EtherDFS that needs a fully wired path on the same LAN segment.

The Ethernet HAT satisfies the need for a wire but a USB connected Ethernet adapter should be much faster even for EtherDFS.

Good morning.

My working etherdfs/netdrive setup:

386 -lan- rasp w/ usb -wifi- internetrouter (won’t be used here)

My smb setup:

386 -lan- openwrt router w/ usb -Wifi- internetrouter (won’t be used actively here)

Heya, mbbrutman!

Thank you so much for all of the hard work on creating mTCP NetDrive so far! I really appreciate it! 😀

What I would like to see is having the starting drive letter when loading NETDRIVE.SYS in the CONFIG.SYS file. For example, my Toshiba Tecra 500CDT has drive letters D: occupied for a PCMCIA CF card, E: for the CD-ROM and drive F: for the RAM Disk and starting drive letter G: would be for NETDRIVE.SYS. I would love it if we could have a option to set the starting drive letter when loading NETDRIVE.SYS.

What do yo think? ^^

Sorry, it can't happen. I think it's even discussed earlier in this exact thread.

When DOS installs a device driver it tells the device driver the first drive letter that it has been assigned. The drive letter is assigned by DOS and it depends on the hardware found on the machine and the other device drivers that were loaded first. The device driver has no control over it. DOS 2.0 doesn't even tell the device driver what the drive letter is. You have to play games to figure that out.

There are programs that allow you to load device drivers later after the boot is complete and even assign drive letters. I haven't found one that works. Those programs needs to muck with DOS internal data structures and even though NetDrive is as simple as it gets those programs are missing something important.

A trick that helps:

In order to reserve a drive letter in DOS for CD-ROMs, networks, etc., you may quite easily create as many tiny dummy ram drives as needed that upon boot take the needed drive unit letters for themselves, only to release them manually from the command line when needed, by invoking its unloading mechanism or a tool such as KILLDRV.

I personally use this trick quite often, in my case for running programs which were badly hardcoded to only run from a D: drive, which is usually associated with CD/DVD drives which I don't have on many of my systems.

I have found that DEVLOAD can try to load mTCP NetDrive in the AUTOEXEC.BAT, but it hasn't been thoroughly tested and may eventually not work correctly, if not at all. For example if drive C is the boot drive and drive D is the CDROM drive, loading NetDrive with DEVLOAD after MSCDEX in the AUTOEXEC.BAT file would obviously assign it as drive E.

However, I found that loading NetDrive with DEVLOAD can be quite a risk.

A better way would be to load Drive Letter Manipulator in either CONFIG.SYS or AUTOEXEC.BAT file: https://sta.c64.org/dlmanipdoc.html

I'll look into the documentation to see how it all can be done. 😀