Re: Developing PLATOTerm64, Flow Control woes.

----- Original Message ----- 
From: "smf" <smf@null.net>
To: <cbm-hackers@musoftware.de>
Sent: Tuesday, July 03, 2018 9:17 AM
Subject: Re: Developing PLATOTerm64, Flow Control woes.


> On 02/07/2018 18:47, Mike Stein wrote:
> 
>> 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'?
> 
> No, if I've already queued 16 bytes to send to you and the transmit fifo 
> is dumb then I can't send an xoff until you've received the other 16 
> bytes. You therefore may need to start sending xoff 16 bytes earlier 
> than you otherwise would.
---------
Well, if your _sending_ end is sending XON and XOFF then I can understand why you have trouble making it work,,,
---------

> The receive fifo's are only a problem if you're not reading from them, 
> which you should do even if you're going to discard the data because 
> your buffers are full.
----------
I'd say the receive FIFOs can indeed be the problem; if you're allowing the buffer to fill and are discarding data then I'd say you're not controlling the flow of data very effectively. Why on earth would I not read the data in the Rx FIFO, especially if it generates an interrupt?
----------

> End to end xon/xoff will never be reliable over the internet. Both 
> RTS/CTS and Xon/Xoff are local handshaking. The internet can deal with 
> it's own flow control.
----------
XON/XOFF can be both local, remote or both.
----------
 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.
> 
> Depends on the latency, buffers and any packet drops. If the other end 
> has 1k sitting in an output buffer waiting for a missing ack to restart 
> sending, then any xoff you send will not help with data loss.
------------
If the other end is waiting for a missing 'ack' then why would I send it an XOFF?
------------

> 
> You might get lucky, but it won't be working properly in all circumstances.
> 
------------
If you say so; presumably the folks who have replaced RS-232 connections with Ethernet are liars, as are the companies that sell 'bridges' to replace both direct RS-232 and modem connections and advertise that no software changes will be necessary and XON/XOFF flow control is an option.

Sorry, I'm having a lot of trouble grasping what you're saying, especially the part about the sending end controlling flow with XON/XOFF; in my world it is the receiving end that is in control.

You say it can't work, I say it can and does; guess we'll have to leave it at that.