Jules_nerd wrote on Yesterday, 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.