It's nice to hear good news once in a while ...

DiskTest should work fine as I have used it before. The Turbo Pascal 6.0 manual says the following:

106 Invalid numeric format: Reported by Read or Readln if a numeric value read from a text file does not conform to the proper numeric format.

If you have a configuration file that DiskTest reads at the start I would delete it or fix it.

mbbrutman wrote on 2024-06-12, 16:03:

It's nice to hear good news once in a while ... […]
Show full quote

It's nice to hear good news once in a while ...

DiskTest should work fine as I have used it before. The Turbo Pascal 6.0 manual says the following:

106 Invalid numeric format: Reported by Read or Readln if a numeric value read from a text file does not conform to the proper numeric format.

If you have a configuration file that DiskTest reads at the start I would delete it or fix it.

Sorry... it was runtime 160. What i get for trying to remember details from a 5am lack of sleep night....

Anyways..

It appears to fail when creating the temporary file. It never completes it.
Seems to be around ~196k give or take each time I run this to generate the 160 error.

Attached image.

160 is "Device Write Fault" ... so you were doing a write and it failed.

NetDrive will retry an operation up to 2 times before telling DOS something is wrong. DOS then usually throws up the critical error handler. In this case it looks like the Turbo Pascal runtime is suppressing the critical error handler, and not giving you the option to retry.

You should only be seeing if this if the same write fails three times in a row. Is you network noisy? How fast is your server? If you run "netdrive status e:" there will be a number of blocks read, written, and a retry count for each device - can you share that output after the error happens?

Mike

mbbrutman wrote on 2024-06-12, 21:23:

160 is "Device Write Fault" ... so you were doing a write and it failed. […]
Show full quote

160 is "Device Write Fault" ... so you were doing a write and it failed.

NetDrive will retry an operation up to 2 times before telling DOS something is wrong. DOS then usually throws up the critical error handler. In this case it looks like the Turbo Pascal runtime is suppressing the critical error handler, and not giving you the option to retry.

You should only be seeing if this if the same write fails three times in a row. Is you network noisy? How fast is your server? If you run "netdrive status e:" there will be a number of blocks read, written, and a retry count for each device - can you share that output after the error happens?

Mike

For most part, this works really well. I've been able to run a number of smaller programs over the netdrive with out issues.

I did an XCOPY of the drive for fun of it to make a "backup" and it worked in the end. But every once in a while, I'd get the write fault error in the picture.
Every time I did retry. It continued on for a while.

E: 192.168.50.212:2002, 654871, 512.dsk (RW0, 900, 112907, 2439

Retries are high.

The "Server" machine is an AMD 5950X CPU... 128gb of ram, 8gb of NVME storage, Windows 11 Pro, blah. Stout system that I never have issues with.

I have 3 Systems sitting on GSS108E managed switch.

The PS/2, the 5950X that most of the time, is sitting doing not much, and an HP EliteDesk I use for my developer job.
But over all not to crazy/busy.

For fun, I've swapped network cable for the IBM. But nothing changed.

Besides the Sergey Kiselev network card, I do have a LPT model of the XIRCOM network adapter I could try.

I feel like I am asking a lot for a 8mhz , 8086 CPU. Not sure if there is any benefits if you were able to detect NEC V20/V30 CPU's for any improvements?

Pictures added here to show some results.

Again... this is really cool and works for most part pretty well and easily. I am liking this very much.

Only thing I could say maybe, is the server side of things.... if was A way to easily browse the contents of HD disk images and such and push/pull files out of them, ect easily.
I get around this with another DOS box on my server to connect, and push files on. My only "gripe" if even that.

I checked the Turbo Pascal 6.0 manual, and yes, it's replacing the DOS critical error handler. That's why you are not seeing the "Abort, Retry, Ignore" message from DOS.

In general it is working as it should. Your server is fine but the network is probably very noisy. Whatever the problem, it's causing UDP packets to be dropped which is hurting performance. If you hit Retry on the DOS error prompt it will resume where it left off without problem. (I tested that feature by both injecting errors on the server side and by unplugging and replugging-in the network cable.)

Things will probably improve if you get the old machine onto a separate switch or subnet. A reasonable switch should not be broadcasting all packets, but some packets like ARP are broadcast by nature. Try running pkttool from mTCP in listen mode to see how many packets are hitting the machine directly.

Sergey's card is going to be better than the Xircom adapter by at least 50% - parallel ports are just bad, and that assumes you have a bi-directional parallel port. The 8Mhz 8086 is also good; I'm usually on a 4.77Mhz V20 and even that is enough to keep up with things. But even the best network card for a vintage computer isn't going to be able to keep up with a flood of ARP requests and broadcast traffic.

I can't work on server side tools for inserting files into images or reading files from images; it's just too much work. Technically easy, but there are some existing tools like WinImage that do that already.

mbbrutman wrote on 2024-06-13, 00:17:

I checked the Turbo Pascal 6.0 manual, and yes, it's replacing the DOS critical error handler. That's why you are not seeing th […]
Show full quote

I checked the Turbo Pascal 6.0 manual, and yes, it's replacing the DOS critical error handler. That's why you are not seeing the "Abort, Retry, Ignore" message from DOS.

In general it is working as it should. Your server is fine but the network is probably very noisy. Whatever the problem, it's causing UDP packets to be dropped which is hurting performance. If you hit Retry on the DOS error prompt it will resume where it left off without problem. (I tested that feature by both injecting errors on the server side and by unplugging and replugging-in the network cable.)

Things will probably improve if you get the old machine onto a separate switch or subnet. A reasonable switch should not be broadcasting all packets, but some packets like ARP are broadcast by nature. Try running pkttool from mTCP in listen mode to see how many packets are hitting the machine directly.

Sergey's card is going to be better than the Xircom adapter by at least 50% - parallel ports are just bad, and that assumes you have a bi-directional parallel port. The 8Mhz 8086 is also good; I'm usually on a 4.77Mhz V20 and even that is enough to keep up with things. But even the best network card for a vintage computer isn't going to be able to keep up with a flood of ARP requests and broadcast traffic.

I can't work on server side tools for inserting files into images or reading files from images; it's just too much work. Technically easy, but there are some existing tools like WinImage that do that already.

I shut down one system. So just the PS2 and the Win11 server. on that manager switch running. And same thing happened.

Here are two screen shots from PKTTOOL

"Warning - failed to set promiscuous mode on your Ethernet card." Shows up.

Says its listening but nothing is showing. Assume the above message is the reason.

It has been sitting for a while now in listen mode but nothing is happening.

Hit escape, and everything is zero.

The stats command will work for this problem ...

I don't know how long you were running for, but you had 17 million packets received during that time. Given how few you sent, that's a lot of incoming packets. Repeat the experiment sometime; just reboot the machine, load a packet driver, and after 10 minutes dump the stats. I'd love to see how many packets you get during that 10 minutes while nothing is supposed to be happening.

One way or the other, you are dropping UDP packets that NetDrive needs to see. It's either bad hardware or a card that is getting overwhelmed with the number of packets coming in. I'm betting you have a very busy network.

mbbrutman wrote on 2024-06-13, 04:00:

The stats command will work for this problem ...

I don't know how long you were running for, but you had 17 million packets received during that time. Given how few you sent, that's a lot of incoming packets. Repeat the experiment sometime; just reboot the machine, load a packet driver, and after 10 minutes dump the stats. I'd love to see how many packets you get during that 10 minutes while nothing is supposed to be happening.

One way or the other, you are dropping UDP packets that NetDrive needs to see. It's either bad hardware or a card that is getting overwhelmed with the number of packets coming in. I'm betting you have a very busy network.

I am 100% sure of it being A busy network being the issue, like you said. Just can't keep up. Being on the same managed switch doesn't really mean much of anything. If that switch is connected to the rest of a busy network.

I rebooted the system and waited 10 minutes. Eeka...

I'll do some networking changes here to possibly get this system on its own quite talk network that has internet access.

I've been using netdrive off and on today, and for most part its worked very well.

Just doing long writes to the Netdrive like XCOPY of a bunch of stuff is only time I really have issues.

Well after some tinkering, got this working really nice now!

I had a small mini wifi router.

Hooked that up to the switch.

IBM plugged into that.

Then had a USB>Ethernet adapter , plugged that into the "server" box... and that to the mini router.

This got the IBM off the noisy network.

After almost an hour, here is the PKTTOOL results.

MUCH better!

Things I noticed

1) DHCP works now. Instant connect. Before I had to static set the IP info.
2) FTP works great now! Before it was spotty and slow.
3) XCopy the entire drive (~100mb of data) to the NetDrive... not a single failure. 2235 files copied.
4) DiskTest runs no problem now. Ran it a bunch of times and not 1 failure.
5) Over all, ALL networking tools/access is so much more stable and MUCH faster too!

So it probably comes down to, if busy network... and using DOS.... put the system behind something that will reduce the traffic down to virtually nothing.
And it will be happy 😀

One thing I noticed ( and sorry if I missed this if mentioned else where as I didn't see it mentioned in netdrive.txt )

If I have NetDrive actively connected to a drive letter and working, I can't seem to use any of the mTCP tools... FTP / Telnet / Ping / HTTPServ / ect.

If I disconnect from the NetDrive, then they all start working again.

Would this be A limitation of NetDrive keeping "a lock" on the packet driver or something in that nature? Only 1 program at a time can be using it?

jdredd wrote on 2024-06-14, 06:39:

One thing I noticed ( and sorry if I missed this if mentioned else where as I didn't see it mentioned in netdrive.txt ) If I hav […]
Show full quote

One thing I noticed ( and sorry if I missed this if mentioned else where as I didn't see it mentioned in netdrive.txt )
If I have NetDrive actively connected to a drive letter and working, I can't seem to use any of the mTCP tools... FTP / Telnet / Ping / HTTPServ / ect.
If I disconnect from the NetDrive, then they all start working again.
Would this be A limitation of NetDrive keeping "a lock" on the packet driver or something in that nature? Only 1 program at a time can be using it?

See the full documentation...

"While the device driver is connected to a remote disk the packet driver and Ethernet device need to be dedicated to the device driver. Other mTCP programs or programs that use packet drivers can’t use that Ethernet card, but they can use a different one."
"A future version of the NETDRIVE.SYS device driver will emulate a packet driver, passing through packets that are not destined for the device driver. This will allow other mTCP and packet driver programs to run even while a network drive image is connected."

Grzyb wrote on 2024-06-14, 06:56:

See the full documentation... […]
Show full quote

jdredd wrote on 2024-06-14, 06:39:

One thing I noticed ( and sorry if I missed this if mentioned else where as I didn't see it mentioned in netdrive.txt ) If I hav […]
Show full quote

One thing I noticed ( and sorry if I missed this if mentioned else where as I didn't see it mentioned in netdrive.txt )
If I have NetDrive actively connected to a drive letter and working, I can't seem to use any of the mTCP tools... FTP / Telnet / Ping / HTTPServ / ect.
If I disconnect from the NetDrive, then they all start working again.
Would this be A limitation of NetDrive keeping "a lock" on the packet driver or something in that nature? Only 1 program at a time can be using it?

See the full documentation...

"While the device driver is connected to a remote disk the packet driver and Ethernet device need to be dedicated to the device driver. Other mTCP programs or programs that use packet drivers can’t use that Ethernet card, but they can use a different one."
"A future version of the NETDRIVE.SYS device driver will emulate a packet driver, passing through packets that are not destined for the device driver. This will allow other mTCP and packet driver programs to run even while a network drive image is connected."

OK nice. Not a huge issue really. Right now I have two batch files to quickly connect/disconnect as needed to get me by.

I am just excited that this is working so well in general now that I got behind its own router to quiet down the network traffic. Haven't had one failure now.

Grzyb wrote on 2024-06-14, 06:56:

See the full documentation... […]
Show full quote

jdredd wrote on 2024-06-14, 06:39:

One thing I noticed ( and sorry if I missed this if mentioned else where as I didn't see it mentioned in netdrive.txt ) If I hav […]
Show full quote

One thing I noticed ( and sorry if I missed this if mentioned else where as I didn't see it mentioned in netdrive.txt )
If I have NetDrive actively connected to a drive letter and working, I can't seem to use any of the mTCP tools... FTP / Telnet / Ping / HTTPServ / ect.
If I disconnect from the NetDrive, then they all start working again.
Would this be A limitation of NetDrive keeping "a lock" on the packet driver or something in that nature? Only 1 program at a time can be using it?

See the full documentation...

"While the device driver is connected to a remote disk the packet driver and Ethernet device need to be dedicated to the device driver. Other mTCP programs or programs that use packet drivers can’t use that Ethernet card, but they can use a different one."
"A future version of the NETDRIVE.SYS device driver will emulate a packet driver, passing through packets that are not destined for the device driver. This will allow other mTCP and packet driver programs to run even while a network drive image is connected."

I've successfully used PKTMUX (attached) to achieve this. It's not super fast, but it works. Be prepared to spend a fair bit of time reading docs, though..
PKTMUX speaks to the loaded packet driver and multiplexes network packets between a number of virtual packet drivers, each of which can be told to handle different protocols/ports and live on different interrupts. That way, netdrive can use one, and other mtcp apps can use another. It takes a bit of juggling, and performance will depend a lot on your NIC and hardware packet driver.
I'm using this in the real world to multitask httpserv.exe, ftpsrv.exe and ircd.exe under DesqVIEW on a 286 :)

/Eirik

PKTMUX is the solution for now.

I'll eventually add the packet driver "pass through" feature to the mTCP NetDrive device driver, making for a more natural and faster experience. However, it will only be available to my followers on Patreon. Each month I'll be unlocking new features and hosting exclusive interviews with my supporters, which I think will be a great way to better serve the community and take future feature requests. For those of you not on Patreon you can follow me on Facebook, X, Instragam, Tiktok and a few other places. But not Google+.

mbbrutman wrote on 2024-06-14, 15:33:

PKTMUX is the solution for now.

I'll eventually add the packet driver "pass through" feature to the mTCP NetDrive device driver, making for a more natural and faster experience. However, it will only be available to my followers on Patreon. Each month I'll be unlocking new features and hosting exclusive interviews with my supporters, which I think will be a great way to better serve the community and take future feature requests. For those of you not on Patreon you can follow me on Facebook, X, Instragam, Tiktok and a few other places. But not Google+.

You got a link for all these places to take us directly to?

Oh gods no, that post was a very sarcastic joke! (I don't have any of those things.)

mbbrutman wrote on 2024-06-14, 23:12:

Oh gods no, that post was a very sarcastic joke! (I don't have any of those things.)

Aw man... Figured you had one of them so us goof balls can bug you in A virtual unlimited number of ways 😜

I follow a number of developers on all the platforms... well maybe not Instagram and TikTok ....

Okay, I've been using mTCP NetDrive in a batch file to start and stop the the NetDrive service. I was going to run the Links text mode browser while the attached network storage is present and when I tried to access Google in text mode, I get this error message:

If I detach the network drives by using a batch file to disconnect the network drives, I can somehow access the internet.

Is this a design limitation of mTCP NetDrive or more of a bug, just to be curious? The DOS binaries for Links browser from Twibright Labs can be found here.

If you want additional information on how I used the batch files to start and stop NetDrive, let me know. 😄

ppgrainbow wrote on 2024-08-30, 01:29:

Is this a design limitation of mTCP NetDrive or more of a bug, just to be curious?

See the docs:

As of this writing mTCP NetDrive requires exclusive use of the packet driver and Ethernet card if it is connected to a remote disk image. You can not run networking programs while a remote disk image is connected unless they are using a different networking device.

To make mTCP NetDrive work the device driver has to take over the processing of packets on the Ethernet device. The device driver is using IP, UDP and ARP and those packet types can not be shared by more than one program. Therefore, other TCP/IP or UDP programs can not use the Ethernet device while a remote disk image is connected. (Think of mTCP NetDrive as just another mTCP program; only one program can use the Ethernet device at a time.)

A future version of the NETDRIVE.SYS device driver will emulate a packet driver, passing through packets that are not destined for the device driver. This will allow other mTCP and packet driver programs to run even while a network drive image is connected.

Grzyb wrote on 2024-08-30, 01:42:

ppgrainbow wrote on 2024-08-30, 01:29:

Is this a design limitation of mTCP NetDrive or more of a bug, just to be curious?

See the docs:

As of this writing mTCP NetDrive requires exclusive use of the packet driver and Ethernet card if it is connected to a remote disk image. You can not run networking programs while a remote disk image is connected unless they are using a different networking device.

To make mTCP NetDrive work the device driver has to take over the processing of packets on the Ethernet device. The device driver is using IP, UDP and ARP and those packet types can not be shared by more than one program. Therefore, other TCP/IP or UDP programs can not use the Ethernet device while a remote disk image is connected. (Think of mTCP NetDrive as just another mTCP program; only one program can use the Ethernet device at a time.)

A future version of the NETDRIVE.SYS device driver will emulate a packet driver, passing through packets that are not destined for the device driver. This will allow other mTCP and packet driver programs to run even while a network drive image is connected.

Thank you for the heads up! I appreciate it. I'm either gonna have to wait until mTCP NetDrive improves or install a second emulated network card. 😀