At these low speeds I'd be surprised if the server needs to buffer anything but
anything's possible.
I don't recall having any problems when connected over a 'real' RS-232 port
using Hyperterm on WIN but I guess I'll have to revisit this one day. Back in
the days when we first put the M100 on the internet ISTR that the issue was the
fact that the 'modem' (or USB<>RS-232 adapter) sends packets instead of
one-byte-at-a-time as with 'real' RS-232, and reducing packet length to 1
character solved the problem.
There's also the issue of whether the USB adapter honors XON/XOFF...
In any case, a blanket statement that file transfer at any higher baud rate
than 600 or 1200 bd is never reliable is a little misleading.
m
----- Original Message -----
From: John R. Hogerhuis
To: m...@bitchin100.com
Sent: Friday, March 22, 2019 10:28 PM
Subject: Re: [M100] 100/102 to USB?
On Fri, Mar 22, 2019 at 6:56 PM Willard Goosey <goo...@sdc.org> wrote:
It's basically bufferbloat on the other side. The PC/Mac/whatev recieves
an XOFF and sticks it in a large recieve buffer and goes on with blasting
bytes at the M100. By the time it gets around to actually *processing* the
XOFF it's already overrun the M100's buffer. :-(
Faster serial transfers work best with things like old DOS term programs
that don't know about 16650 FIFOs. ;-)
I never had any trouble with Procomm under msdos on a 386. Minicom under
Linux is nothing but trouble!
My experience is the same. I've found it to be Linux specific. That's why
hardware flow control, or inserting some delays is the only way to avoid
overrun.
Also the USB-Serial drivers add some buffering so that's another variable.
Windows doesn't seem to have the problem based on most reports.
I think the fix would be for Linux to read ahead in its buffers for XOFF
character to see if it needs to flow-off. But I doubt the maintainer will fix.
At some point it was Alan Cox. I don't think there's any way to fix this
outside the kernel.
-- John.
