from the user's perspective, I have. What else can I realistically do? If I am having to work around the problem in modem firmware, I've lost. and I am not able to alter very low level system code (which is written in CDC assembler, do any of YOU know how to program a 60-bit control data supercomputer?) ;) sooo again.. if anyone has any better ideas, lay them on me. -Thom On Tue, Jul 3, 2018 at 1:05 AM David Roberts <daver21145@gmail.com> wrote: > 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. >>>> > >>>> > >>>> >>>>Received on 2018-07-03 09:00:25
Archive generated by hypermail 2.2.0.