mbbrutman wrote on 2024-02-22, 01:58:

@anderswk […]
Show full quote

@anderswk

I'm still missing some detail - what exactly is the machine doing when it stops working? Is the whole machine frozen? Is it just the network drive that doesn't work? You say it happens after 10 seconds - is it just idle during that 10 seconds or are you doing something during that 10 seconds?

Win98 DOS is fine - I just tested it on a P133 system with a LinkSys PCI card. I don't have a 3Com Etherlink 100 that matches your card to test with.

Unfortunately without having access to the machines that don't work it's difficult to figure out what might be going wrong. I'm not doing anything tricky or fancy in the code that would be different from the way another mTCP program uses it. The leading cause for problems like this is stack corruption. I think I allocated a generous amount of stack space but it is possible a specific packet driver needs more. If I sent you a debug version via email that has more stack space allocated would you be willing to test it?

It freezes after 10s of idling at the prompt after I call netdrive connect. During the 10s I can still type input, but after that it freezes and I need to power cycle (ctrl-alt-del doesn't work).

Ok, so if you are just typing then there should be no disk activity, right?

Can you try connecting to a network drive and then disconnecting the network cable right away? Based on what you said it's not happening during disk activity, so it must be a packet arriving or the machine trying to respond to an ARP request during the timer tick interrupt. Obviously the net drive won't work, but if you are on your C: drive and everything continues to operate as usual then I know where to look for possible problems.

Also, I asked earlier but did not see a response - are you willing to run a test version of code?

anderswk wrote on 2024-02-21, 17:00:

Packet driver is "3Com EtherLink PCI Bus Master Packet Driver v5.2.6", 3C90XPD.EXE.

The most recent 3x90XPD drivers are just broken in multiple ways and are best avoided. If you don't have a 905C, "downgrade" to earlier versions of the packet driver or use a different ethernet card. You might also try a setup with an ODI packet driver layered on top of a 3COM ODI driver. Spurious lockups and crashes with 5.2.6 are not surprising. I reverse engineered enough of exactly that driver version to give up on the idea of "just fixing" it.

mkarcher wrote on 2024-02-23, 02:32:

anderswk wrote on 2024-02-21, 17:00:

Packet driver is "3Com EtherLink PCI Bus Master Packet Driver v5.2.6", 3C90XPD.EXE.

The most recent 3x90XPD drivers are just broken in multiple ways and are best avoided. If you don't have a 905C, "downgrade" to earlier versions of the packet driver or use a different ethernet card. You might also try a setup with an ODI packet driver layered on top of a 3COM ODI driver. Spurious lockups and crashes with 5.2.6 are not surprising. I reverse engineered enough of exactly that driver version to give up on the idea of "just fixing" it.

Eeek! Thanks for posting that ... you just saved me time trying to debug something that might be beyond my control.

I get suspicious when something works with the existing mTCP programs, but possibly breaks with NetDrive. NetDrive is different in that I coded everything in assembler from scratch. However, fundamentally it does not use the packet driver in a different way. And it's been working for most people, save an occasional report like this one.

mbbrutman wrote on 2024-02-23, 02:51:

Eeek! Thanks for posting that ... you just saved me time trying to debug something that might be beyond my control.

I get suspicious when something works with the existing mTCP programs, but possibly breaks with NetDrive. NetDrive is different in that I coded everything in assembler from scratch. However, fundamentally it does not use the packet driver in a different way. And it's been working for most people, save an occasional report like this one.

Guess how I know that the 3c90xPD driver is broken? It fails to work reliably with EtherDFS, too. I don't remember whether I tried mTCP stuff on it, but its quite likely. The broken 3com packet drivers already were a topic here on VOGONs, possibly in an EtherDFS-related thread. That driver has issues like reserving a byte for a word-wide variable, or depending on the contents of uninitialized memory. Behaviour might be very erratic (I might have experienced that EtherDFS only works kind-of reliably if I run a specific mTCP program beforehands, but I don't remember the details anymor).

Thanks for the additional context. Things like not properly initializing storage, using storage you didn't allocate, etc. are very difficult to debug. And well, also kind of rookie mistakes. It's hard to believe the 3Com code on the later packet drivers is that bad, but I'll take your word for it. The standard mTCP programs use code generated by a compiler with a much different memory layout. The compiler code gen is also be much less efficient, resulting in registers being reloaded when they don't need to be, which would cover sins elsewhere like in the packet driver. So while I don't think have any bugs in this code, bugs in the packet driver can be exposed by these subtle differences.

I found a small horror show in the PCjr BIOS during testing. The code would run fine, but then I tried to interrupt it while it was transferring data and the machine crashed. While I knew the PCjr used the NMI interrupt for keyboard handling, what I didn't know is that it was re-enabling the other interrupts temporarily too. So you could be running interrupts disabled for a good reason, hit a key, and then have interrupts back on when they should not be. And worse, the interrupt handling code was a pig and using too much stack space so it was corrupting things beyond the stack. It never happened in the standard mTCP programs because the stack is much more generous on the compiler generated code. (I've since made the stacks in NetDrive very large too.)

Thanks for the time you spent delving into that specific problem. I'm going to find the thread to get the details.

mbbrutman wrote on 2024-02-23, 21:59:

Thanks for the additional context. Things like not properly initializing storage, using storage you didn't allocate, etc. are very difficult to debug. And well, also kind of rookie mistakes. It's hard to believe the 3Com code on the later packet drivers is that bad, but I'll take your word for it. The standard mTCP programs use code generated by a compiler with a much different memory layout. The compiler code gen is also be much less efficient, resulting in registers being reloaded when they don't need to be, which would cover sins elsewhere like in the packet driver. So while I don't think have any bugs in this code, bugs in the packet driver can be exposed by these subtle differences.

...

Thanks for the time you spent delving into that specific problem. I'm going to find the thread to get the details.

I'm sorry if I set wrong expectations. I didn't explain the technical issues with this driver in detail in those threads. Instead, I referred to it because IIRC it contained recommendations for older working 3com drivers.

I specifically thought about:

Re: Getting a 3COM Fast Etherlink XL 10/100Mb TX (3C905-TX) Card to run in DOS?

mTCP hangs..

mbbrutman wrote on 2024-02-23, 00:32:

Ok, so if you are just typing then there should be no disk activity, right?

Can you try connecting to a network drive and then disconnecting the network cable right away? Based on what you said it's not happening during disk activity, so it must be a packet arriving or the machine trying to respond to an ARP request during the timer tick interrupt. Obviously the net drive won't work, but if you are on your C: drive and everything continues to operate as usual then I know where to look for possible problems.

Also, I asked earlier but did not see a response - are you willing to run a test version of code?

I tried the big stack version and it hangs right after: NetDrive device opened, IOCTL_read return code: 8 0254:0020 0254:184E

Also tried 4.0d version of packet driver as mentioned in other thread, but no difference. Also tried -t -r options.

But.. small progress: If I use the regular stack version and unplug network cable right after netdrive connect, then it doesn't crash. I then plugged in the cable again and could even do a dir of the network drive and see remote folder. However, the computer hung before the dir command finished.

I was kind of hoping that allocating a lot more stack space would help, but your results show that it is just as random. I don't think the NetDrive code is at fault here.

At this point I'm going to suggest getting a different model of network card. In the other thread somebody also reported that a really old version of the driver (2.0?) worked for them, but at this point we are "just throwing pasta at the wall to see if it sticks."

I'll see if I can find one of these cards so that I can debug it here. That's going to be much more efficient than the back and forth through email.

mbbrutman wrote on 2024-02-24, 17:27:

I was kind of hoping that allocating a lot more stack space would help, but your results show that it is just as random. I don't think the NetDrive code is at fault here.

At this point I'm going to suggest getting a different model of network card. In the other thread somebody also reported that a really old version of the driver (2.0?) worked for them, but at this point we are "just throwing pasta at the wall to see if it sticks."

I'll see if I can find one of these cards so that I can debug it here. That's going to be much more efficient than the back and forth through email.

I already swapped it for an 3C509 ISA card.

And does the 3C509 work?

mbbrutman wrote on 2024-02-24, 23:48:

And does the 3C509 work?

Yes, works fine.

Dear all,

I just tried out netdrive as well as etherDFS on my 386:

1. really great work from both developers
2. I couldn’t come across 150KB/s. Via MSClient SMB it’s 300kb/s
3. mounting an iso via etherDFS and then shcd is successful at first (in contrary to MSCLIENT) but accessing files then on that iso let the system freeze
4. did not test yet point 3 with netdrive since performance impact was too large for me

Maybe I’ll take the NFS challenge next.

Again thanks all for the work anyhow!
Regards

What does your setup look like? On my 386-40 I get around 400KB/sec reading or writing using NetDrive.

Here are some numbers:

• PS/2 Model 25 (8086) with 3Com 3C503: 134KB/sec (reads and writes)
• Generic 80386-40 Davicom NIC: 390KB/sec (reads and writes)
• Generic 80486-66 SMC ISA NIC: 544KB/sec for writes, 436KB/sec for reads
• Generic Pentium 133, Linksys PCI NIC: 1372KB/sec writes, 1308KB/sec reads

Sure:

- generic details see signature
- 3com 509b nw using the 905b using the 3c509.com packet driver
- 15mhz ISA
- Netdrive Host = raspberry pi Zero 2w with latest 64Bit Debian rasp OS
- image on USB stick fat formatted (for etherDFS)

Hm nothing more comes to mind currently. Maybe this helps a bit. Thanks

Marco wrote on 2024-04-27, 05:04:

Sure: […]
Show full quote

Sure:

- generic details see signature
- 3com 509b nw using the 905b using the 3c509.com packet driver
- 15mhz ISA
- Netdrive Host = raspberry pi Zero 2w with latest 64Bit Debian rasp OS
- image on USB stick fat formatted (for etherDFS)

Hm nothing more comes to mind currently. Maybe this helps a bit. Thanks

The 3C509 is fine. I'm not sure about 15Mhz ISA - ISA is good from 4.77Mhz to about 8 and anything else might be getting a significant number of wait states.

The Pi Zero 2W is has two problems; it's a bit weak on the CPU and it's on WiFi. Wifi in particular is bad, as it adds a lot of latency to the connection. You can only get 1KB through the connection per round trip (packet send and receive), so 4 or 5 milliseconds on a ping are going to translate to lower data rates.

My 386-40 has quite a bit more CPU but I only run the card at 8Mhz. The server is a Windows machine on a wired connection. I can run against my Pi Zero 2W, but it's much slower for the reasons stated above. Even a Pi5 on WiFi is half the speed of a Pi5 on a wired connection.

Thanks a lot some infos I missed. The pi is connected via Ethernet to the retro via usb/eth hat (these plug ontop via gpio to get more usb and Ethernet connectors). The raspberry acts as Ethernet accesspoint via dnsmasq.
All 16BIT waitstates are lowest selectable

Maybe this helps a bit

Is the Ethernet HAT connected using the SPI pins? If you run a network speed test what rates do you see? If you ping from DOS what is the round trip time?

The 386 is fast enough. The code is limited by the round trip packet time. I'll benchmark my Pi Zero 2W tomorrow so that I can tell you what to expect.

UPS sorry don’t know about SPI, I plug into onto the gpio pins all 40 and that’s it. No driver no manual enablement or so.
Using samba via the raspberry it’s more than 2-3mb/s accesses from a modern pc.

Unfortunately I just lent out my raspberry so at the moment no testing possible. I am anyway looking forward to your results. With such a setup I really can’t imagine high RTT occur but you never know.

Thanks

Short story: I think your wired Ethernet is not what you think it is.

The Raspberry Pi doesn't have a full bus on the GPIO pins. It does have serial ports, power, and some other functions. One of those functions are SPI (Serial Peripheral Interface) pins, which can be used to attach things like USB or Ethernet controllers. I don't know SPI well but it's going to be limited in performance compared to something more directly connected.

First, let's stress testy the Raspberry Pi Zero 2W. I ran these tests using a virtual machine on a pretty large Windows system with the RaspPi has the server. The point of this test is to find the absolute maximum the Raspberry Pi Zero 2W can put out:

Ping time between Windows hosting the virtual DOS machine and Raspberry Pi Zero 2W

• Wifi: average 2.218ms
• Ethernet: average 0.562ms

Given those ping times the maximum data rates from a virtual machine running on the Windows machine to the RaspPi through Netdrive are:

• Wifi: 450KB/sec
• Ethernet: 1779KB/sec

And here are the actual measured speeds for 1MB of reads and writes through NetDrive. (Run a few times and averaged):

• Wifi: Around 420KB/sec
• Ethernet: Around 975KB/sec

The USB Ethernet was connected to the USB port on the Pi using an OTG cable. I actually had it connected through a powered USB hub because the power draw is a lot for a RaspPi Zero. I also had a fan blowing on the RaspPi to ensure it did not thermally throttle itself.

But you can see the wired USB is clearly superior, both in the ping time and the NetDrive throughput.

The 386-40 only has a 10MB ISA Ethernet card. Ping time through the WiFi interface the average ping time is 3.0ms. Ping time to it through the USB Ethernet adapter averages 0.97ms. That is going to limit the speeds to 333KB/sec on WiFi or 1030KB/sec through Ethernet.

Actual speeds:

• Wifi: Around 230KB/sec
• Ethernet: Around 389KB/sec

This machine never reaches the theoretical maximum speeds. It hits 70% of the theoretical speed on WiFi and 38% of the theoretical speed on Ethernet. This is where a faster machine or a better Ethernet card would help.

Some quick back of the envelope math ... your 25Mhz machine is 62.5% of my 40Mhz machine. Assuming Wifi in the path, the Wifi costs 3ms and the DOS machine is adding another 1.35ms of processing time which is why the throughput is at 230KB/sec, not 333KB/sec. Assuming that processing is influenced purely by clock rate your machine probably requires 2ms of processing time per 1KB packet. Your throughput to NetDrive on the WiFi interface should be around 200KB/sec.

If your Ethernet HAT device is doing less than that then you should try the WiFi interface to see if it is faster. Your Ethernet HAT probably suffers from less lost packets than WiFi but I strongly suspect it is dramatically limiting your network performance. Another potential problem is if you are testing on storage that is on a USB stick connected to the HAT.