Jules_nerd wrote on 2025-08-28, 14:14:

But even just accessing windows shares over the network seems a little slower than I thought it should be, I mean even a 386 can handle TCP/IP over a network adapter at decent rates, so surely it cant be the processor struggling with TCP/IP.... so 6KB/S seems a bit poor for a 115200 baud rate link, unless the overhead is much higher than I thought?

Let's do some basic math ...

Assuming the serial connection is keeping up and not dropping bytes, 115,200 bits per second (not baud, but bits per second) is 11.25KB/sec maximum. It will never exceed that.

I forget what overhead SLIP adds, but it's minmimal. You still generally have a fake Ethernet header for compatibility with the programs that are expecting a packet driver. And then you have 40 bytes of IP and TCP headers even before you get to your data, but on larger data transfers that cost is amortized.

If your machine is using a 16550 style UART you are getting 16 or 64 bytes at a time on each interrupt. If it is an 8250 style UART it is being interrupted for each byte, and it would be faster to using polling instead of interrupts. After you get the packet it has to be copied to the program, processed, and then something can happen. So unless you are doing a pure speed test, you will never get 11.25KB/sec out of it. Especially if you are writing to storage, as FTP does.

Yep, serial sucks for large transfers.

Good to hear a view from someone that knows whats going on under the hood so to speak... Im a hardwre guy & an analogue one at that!
Ahh yes,.... as soon as I think of modems etc the word baud pops into my head....my mistake! and my 14KB/S ish max rate was wrong.. i guess I'd forgotten the start and stop bits? so we have 10 bits per byte of data transfered over the serial port...
I never expected it to be quick, But still.... Im seeing 6KB/S max... just on large file transfers. So we are still loosing something somewhere... I was hoping to get closer to 10KB/S
With 40Bytes I was guestimating say, 10% overhead from the TCP/IP headers?
Its prob as you say down to how fast its managing to deal with all the data from the 16550 UART... This is more or less what I was thinking when it is using a web browser - a lot of processing time is taken up with just rendering the web page... & in those circumstances Im generally seeing less than 1KB/S
I'll do some tests with simple transfers using DOS based utilities & see what that delivers...
If 6KB/S is the best it can do... then I can live with that for the convinience of WiFi... 😀
But Ill dig a bit deeper just to see if I can squeeze a little more out of it... are MTU settings etc likely to help?

It's generally 10 bits per bytes transferred, assuming you are using No parity ,8 data bits, and 1 stop bit.

While Ethernet benefits from large MTU sizes (1500 being the largest possible), I would experiment with cutting the MTU size down on a serial connection. MTU 576 should work for most things, with NetDrive being an exception. (NetDrive expects the MTU to be 1200 or more to avoid fragmentation.) The reasoning is that if you are dropping bytes at the UART or experience corruption, it will be detected more quickly and there is less to retransmit.

At MTU 576 you will be approaching nearly 10% overhead for the fake Ethernet header, IP and TCP headers. But that should still get you to 10KB/sec of throughput. Almost any hard drive should be able to read or write at least 80KB/sec, so if you are doing file transfers you are probably not constrained by the hard drive. You might just have excessive packet retries.

Many thanks for your suggestions of course the whole mTCP suite!
Ive done lots of tests now.
Im seeing between 9 & 10KB/sec transfers in Win95 using windows files shares, in both directions - so its flying! (OK, my expectations have been well and truely managed! 😉 ) So obv thats as good as can be expected. Not sure why i was thinking/getting 6KB/sec before. Ive done so many tests etc Im not sure if Ive changed something.... its also possible that late at night after a couple of beers I thought 1min=100secs!! 😁

Ive used the mTCP spdtest & nc (your DOS one) to do some tests from DOS. This machine (pocket 386) has a compact flash instead of a hard drive, it doesnt use it in a way that makes the most of it, but still gets something like 350 -450KB/sec -not 100% sure on the exact figures, its been while since I tested, but fast enough anyway...
I set up a DOS 6.22 test machine to transfer to/from, a 233mmx with a 3com 905b card.

No problem transfering from the pocket386 to the 233mmx, its happy with mtu=1500. and achieves a transfer rate of over 10.2KB/sec!!
Not so transfering the files from the 233mmx to the pocket 386, neither nc or spdtest (at the pocket 386 end, always nc at the 233mmx end) would work with mtu=1500; the nc running on the 233mmx would finish, but nc on the pocke386 would hang and I had to ctrl C & Alt x out of it. With mtu=1500 and spdtest at the pocket 386, it would complete, but had only transfered something like 3/4 of the 1MB test file...
when using mtu=1500, the activity light on the esp-12 modules only flashed sporadically, it would flash once a second 3 or 4 times, then have a brief burst of activity, then go back to flashing once a secend...
if it helps figure it out, there is no hardware flow control on the serial port between the esp-12 and the 16c550 on the pocket386...

Tests with lower mtu like 512 worked fine on nc, files transfered fine a little slower than you would expect from the ratio of 40 bytes to the mtu, but not far off @ 8.2KB/sec. However, the results from sptest had me puzzeled, it gives a warning about the packet size being smaller than expected.
Regardless of how low i set the MTU, spdtest always gave me this warning. Ive attached some outputs from sptest @ a few different mtus.

It does seem that Im gettign the transfer rates that are reasonable now (ok still slow in wfw 311 when web browsing, but it cant process the web page & images much faster anyway...) but what is causing the warning? does it point to something I could set up better?

Ill try some DOS network apps next!
thanks