Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!netcom!gandrews
From: gandrews@netcom.COM (Greg Andrews)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: XON/XOFF flow control (was re: 19200 baud amiga)
Summary: It can prevent data loss if it's done right.
Message-ID: <26673@netcom.COM>
Date: 3 Mar 91 19:16:51 GMT
References: <19397@cbmvax.commodore.com> <18c3c536.ARN0e77@ea <1047@faatcrl.UUCP>
Followup-To: comp.sys.amiga.datacomm
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
Lines: 32

In article <1047@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes:
>
>  XON/XOFF handshake is a different matter at high rates though, it always
>drops a few characters.
>

Then something's wrong with the buffering used by the communications
programs, or with the threshold where the receiver cries "stop!".
XON/XOFF flow control itself shouldn't cause dropped characters,
the comm programs aren't handling it right.

The nature of XON/XOFF flow control will allow about 3-5 characters 
through before the data flow stops.  If the sender doesn't pay close 
attention, it may send more than that.  If the receiving comm program 
sends an XOFF without enough space left in the buffer, yes, data will 
be lost.

I've seen a few comm programs (on other personal computers) that
wait until their buffer is completely full before sending.  With
RTS/CTS that might work (stressing the "might"), but with XON/XOFF
it probably won't.  XON/XOFF flow control really should happen when
there's room for 10 or more characters in the buffer.

Then again, if the sender won't stop within the number of characters
the receiver can handle, then it won't work either.  IMO, a sender
that won't stop within 10 characters after an XOFF needs to pay
closer attention to the receiver.

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