Re: Developing PLATOTerm64, Flow Control woes.

If you are throttling things, then presumably you haven't 'fixed' the
problem - you have just made it less likely to occur...

Dave

On Tuesday, 3 July 2018, Thom Cherryhomes <thom.cherryhomes@gmail.com>
wrote:

> Wouldn't you know, extreme throttling of the connection with the following
> chunk of code running as a proxy causes everything to come in. :)
> https://gist.github.com/tschak909/a8e86e4fbed46eafac6350b17aecd2ea
>
> Now it's me, in the lab fiddling with this until I can come up with
> something that works with as little active involvement as possible. :)
>
> Anybody with insights or wants to experiment, let me know, and I can get
> you a D64 with the terminal and either a user account or use the guest
> account. :)
>
> -Thom
>
>
>
> On Mon, Jul 2, 2018 at 12:52 PM Thom Cherryhomes <
> thom.cherryhomes@gmail.com> wrote:
>
>> The solution to me seems quite clear, I need to implement traffic shaping
>> to throttle the connection down to something resembling modem speeds, while
>> making a simple form of negotiation with my terminals to specify how much
>> to throttle the connection.
>>
>> -Thom
>>
>> On Mon, Jul 2, 2018 at 12:49 PM Mike Stein <mhs.stein@gmail.com> 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'?
>>>
>>> "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.
>>> >
>>> >
>>>
>>>