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: further discussions about XOFF lag...
Message-ID: <27047@netcom.COM>
Date: 6 Mar 91 01:57:42 GMT
References: <1051@faatcrl.UUCP> <26918@netcom.COM> <1057@faatcrl.UUCP>
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
Lines: 53

In article <1057@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes:
>gandrews@netcom.COM (Greg Andrews) writes:
>
>>If the receiving computer didn't react quickly (sending the XOFF), 
>>or the transmitting computer didn't react quickly (recognizing the 
>>XOFF and pausing transmission), then you could get an overflowed 
>>buffer only at high speeds.
>
>Being sent at a faster rate leaves less time for the cpu to react to 
>the XOFF, so more data slips past before the device stops sending data.
>

You make it sound as if the cpu is a different entity than that which
is transmitting the data.  Why can't the input routines set a "don't
transmit" flag as soon as the XOFF is received, which is checked by
the output routine before it sends each byte?  That would let only a
couple of bytes 'slip past' before the flag is set and transmission
is paused.

>
>>Since XON/XOFF is a 'slower' method of flow control (meaning more 
>>characters can come in before the flow stops), the threshold for 
>>XON/XOFF should be lower than that for RTS/CTS.
>
>Normally, CTS/RTS is hardware controlled and XON/XOFF is software
>controlled.  On the Amiga, both are software controlled.
>

On the IBM PC they are also both software controlled.  That doesn't mean
the serial handling routines should react more slowly for one method than 
they do for the other.  Rather, it argues that they should be identical
in speed, since (presumably) the same routine handles them both.  The
inherent characteristics of XON/XOFF will mean the transmitter won't
receive the XOFF as fast as the hardware signal, but it should stop
transmitting in the same amount of time after it gets there.

It sounds more and more like the XOFF threshold is the same as the RTS
threshold, and there isn't enough extra room in the buffer to handle the
characters that come in.  Since the RTS signal reaches the transmitter
more quickly, the transmitter overruns with fewer characters.  Still,
this should be understood and the XOFF threshold lowered to compensate.

Has anyone set up a routine to count the number of characters received
after sending an XOFF or dropping RTS?  Your other post remembering a
threshold at 90% of a 2K buffer would still indicate that more than 20 
characters are being received after an XOFF.  I could understand 5-7
characters, but 20?!?


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