XON/XOFF was much more useful in 'the old days' although as you say it's still useful in certain circumstances.
But yes, with so little space above the high water mark the M100 needs either a bridge with a large buffer* or *a small packet size if possible, preferably one character just like 'real' RS232 (although that is somewhat inefficient). IIRC when Steve and I were doing some testing years ago I used a LANtronix UDS-10 which was popular on eBay at the time and it did let you set the buffer size to one character and worked pretty well at higher rates. On Tue, Apr 27, 2021 at 1:28 AM John R. Hogerhuis <jho...@pobox.com> wrote: > > > On Mon, Apr 26, 2021 at 7:04 PM Mike Stein <mhs.st...@gmail.com> wrote: > >> WiFi adds an extra element to the problem because unlike >> one-character-at-a-time RS232 the data is in uninterruptible packets; when >> the M100 sends an XOFF to stop sending, the other end doesn't respond until >> it's finished sending the current packet and since the M100 doesn't send >> the XOFF until its buffer is almost full already you'll almost certainly >> overrun the buffer. >> > > The other end... I guess it depends on how the bridge device is written. > It can arrive in big chunks, delayed chunks, etc... as long as there is > enough buffer it still has to go through the skinny RS232 straw, which is > supposed to be flow controlled. And that XOFF would be Model T -> device. > There should be no delay right? Since the one that processes it is the > bridge device not the machine on the other end of the TCP connection. > > Now if you think it is actually relying on dropping packets during XOFF so > that the TCP window closes... yeah that has to go through a lot of back and > forth logic to get the flow to stop. > > I think it should all comes down to how much buffer is available in the > bridge device and how immediately the bridge is designed to respond to XOFF > > Like we found with Windows versus Linux, an OS can be very responsive to > XOFF like Windows and everything works, or have bad buffering delays going > on like Linux and it doesn't work with Model T at all. > > What I think delays XOFF is if the receiver of XOFF (the bridge in this > case) gets "behind" AND processes the XOFF in-band as opposed to on > arrival. So say a lot of bytes are buffered by the bridge device to be sent > (because it is flowed off by the remote TCP socket), and then XOFF comes in > behind that and is not processed until every byte in front of it gets > processed. > > That's the problem with software flow control. To flow off the receive > channel efficiently depends on the receiver of XOFF on the transmit channel > processing XOFF out-of-band. > > This is why hardware flow control is by default, better... it is always > "out of band" and not queued up on a separate channel. > > XON / XOFF can be efficient too but it depends on the implementation > handling flow control as it comes in the port rather than after queueing > and buffering. > > -- John. >
