I'm a little confused and don't quite understand what you're saying: "The problem is large transmit fifo's "... "If you also have a large dumb transmit fifo"..." Did you mean 'receive'? "This affects you whether you're using packets or an ascii terminal" Aren't we talking apples and oranges here? An ASCII terminal communicates with whatever it's connected to, whether that's a packet 'modem' of some kind, a 'normal' modem or a direct connection. The bottom line IMO is that if it's available then RTS handshaking is the way to go; if not, and you can live with the 'no binary' restriction then end-to-end XON/XOFF flow control can work just fine over the internet. With properly configured hard- and soft-ware, effective flow control is quite possible. Most of these devices are intended to transparently replace an RS-232 connection, so if it works over copper wire it should work just as well over USB, Ethernet, WiFi, whatever. m ----- Original Message ----- From: "smf" <smf@null.net> To: <cbm-hackers@musoftware.de> Sent: Monday, July 02, 2018 4:10 AM Subject: Re: Developing PLATOTerm64, Flow Control woes. > On 01/07/2018 20:22, Mike Stein wrote: >> Keep in mind that XON/XOFF expects a fairly immediate response; a common issue using it these days is that you're not necessarily receiving single characters but packets and you could receive quite a few characters before XOFF has any effect. > > The problem is large transmit fifo's and the uart neither understands > the concept of flow control, nor allows the driver to pause > transmission. If you also have a large dumb transmit fifo, then it may > be a while before you can tell the other end to stop sending (and if the > other end has sent an xoff then someone is going to be losing data). > This affects you whether you're using packets or an ascii terminal. > > xon/xoff also shouldn't be used as an end to end flow control over a > modem/the internet as the transmit fifos in those will certainly swamp you. > > sending xoff as soon as you start receiving and only sending xon once > all the data has been processed is as extreme as you can get, if that > doesn't work then the problem you're trying to solve is actually elsewhere. > >Received on 2018-07-02 20:00:04
Archive generated by hypermail 2.2.0.