Path: utzoo!news-server.csri.toronto.edu!rutgers!sun-barr!decwrl!pacbell.com!tandem!netcom!gandrews
From: gandrews@netcom.COM (Greg Andrews)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: XON/XOFF flow control
Summary: Another try.
Message-ID: <27504@netcom.COM>
Date: 9 Mar 91 03:52:37 GMT
References: <1057@faatcrl.UUCP> <27047@netcom.COM> <1065@faatcrl.UUCP>
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
Lines: 37

In article <1065@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes:
>gandrews@netcom.COM (Greg Andrews) writes:
>
>>You make it sound as if the cpu is a different entity than that which
>>is transmitting the data.
> 
>  It's not so much *how* it reacts to the XOFF, it's more of how fast it
>can react.  Serial input and output are asynchronous to each other and
>since the Amiga can send serial data much faster than it can receive it,
>you're gonna have this problem.
>

I guess you're saying this:

"The input and output processes are separate from each other, and there 
is no close communication between them.  If the input process detects an 
XOFF, the output process doesn't get notification right away, so there is 
some delay.  The time delay is long enough that higher speeds will let more
characters through, causing buffer overflow on some receiving systems."

And my reponse would be:

"That sounds like a poor design.  Serial drivers on the IBM PC seem to
face the same issues (all flow control in software rather than hardware)
without incurring the reaction delay that we're talking about here.
A high-speed communications system that supports flow control MUST be
able to react to that flow control quickly."

Or is the explanation "there's something in the hardware that prevents 
the output from halting quickly after an XOFF is received..?"

What is it?

-- 
.-------------------------------------------.
| Greg Andrews      |   gandrews@netcom.COM |
`-------------------------------------------'