gandrews@netcom.COM (Greg Andrews) (03/04/91)
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 | `-------------------------------------------'
jprad@faatcrl.UUCP (Jack Radigan) (03/04/91)
gandrews@netcom.COM (Greg Andrews) writes: >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 Amiga serial.device does the XON/XOFF handshake in this case, not the comm program. Like I said, at slow baud rates XON/XOFF is fine. At higher rates a few characters get lost. It needs to do some scaling to alter the trigger count down proportionally to the baud rate in use. -jack-
WGLP09@SLACVM.SLAC.STANFORD.EDU (03/05/91)
Jack, I think you're wrong. I have had to increase the size of the serial
buffer on occasion, but when I did the lost characters problem always went
away. I think the Amiga serial device sends an Xoff at some fraction (80%?
90%?) of the buffer size. Sometimes, especially with packet services, it
just takes too long for the host to get the message, but increasing the
buffer size usually fixes it.
Willy.
----------
Willy Langeveld - Bitnet: WGLP09 @ SLACVM - BIX: langeveldgandrews@netcom.COM (Greg Andrews) (03/05/91)
In article <1051@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >gandrews@netcom.COM (Greg Andrews) writes: > >>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 Amiga serial.device does the XON/XOFF handshake in this case, not the >comm program. Like I said, at slow baud rates XON/XOFF is fine. At higher >rates a few characters get lost. It needs to do some scaling to alter the >trigger count down proportionally to the baud rate in use. > The need to 'scale down' the XOFF threshold implies that there's something that's timing dependent going on. Since you would get fewer characters in the port, you don't overflow the leftover buffer. This still sounds wrong to me. The XOFF is sent to the transmitting computer at the faster speed also. It should be recognized in time to halt transmission only a couple of characters later. 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. Another possibility is that the thresholds for RTS/CTS handshaking and XON/XOFF flow control are the same, and don't leave much room for overruns. 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. -- .-------------------------------------------. | Greg Andrews | gandrews@netcom.COM | `-------------------------------------------'
jprad@faatcrl.UUCP (Jack Radigan) (03/05/91)
WGLP09@SLACVM.SLAC.STANFORD.EDU writes: OB >Jack, I think you're wrong. I have had to increase the size of the serial >buffer on occasion, but when I did the lost characters problem always went >away. I think the Amiga serial device sends an Xoff at some fraction (80%? >90%?) of the buffer size. Sometimes, especially with packet services, it >just takes too long for the host to get the message, but increasing the >buffer size usually fixes it. Hmm, I'll have to check that again. I recently changed JR-Comm to use the buffer size in Preferences rather than forcing it to an 8k size. I forget when I did the XON/XOFF tests though, before or after. If it was after, then the buffer size was 2k. If the device does indeed work as a percentage of the buffer size, that's better, but using the baud rate in the calulation would be best, agreed? -jack-
jprad@faatcrl.UUCP (Jack Radigan) (03/05/91)
gandrews@netcom.COM (Greg Andrews) writes: >This still sounds wrong to me. The XOFF is sent to the transmitting >computer at the faster speed also. It should be recognized in time >to halt transmission only a couple of characters later. 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. >Another possibility is that the thresholds for RTS/CTS handshaking >and XON/XOFF flow control are the same, and don't leave much room >for overruns. 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. So, a different value must be used for each method since I see data loss with XON/XOFF and not CTS/RTS. -jack-
gandrews@netcom.COM (Greg Andrews) (03/06/91)
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 | `-------------------------------------------'
jprad@faatcrl.UUCP (Jack Radigan) (03/08/91)
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. 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. 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. -jack-
gandrews@netcom.COM (Greg Andrews) (03/09/91)
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 | `-------------------------------------------'
urjlew@uncecs.edu (Rostyk Lewyckyj) (04/04/91)
Regarding RTS/CTS vs. XON/XOFF flow controll.
If I am communicating via some chain of boxes especially including
modems, can I expect RTS/CTS to work, and if so would someone
kindly explain how this would work.
I can easily understand XON/XOFF working, that's program control.
But RTS/CTS as I understand it depends on controlling a signal on
a particular wire of a direct connection between the hardware ports,
with of course programmed recognition of that state of the hardware.
Please reply via e-mail preferably to my bitnet mailbox.
-----------------------------------------------
Reply-To: Rostyslaw Jarema Lewyckyj
urjlew@ecsvax.UUCP , urjlew@unc.bitnet
or urjlew@uncmvs.acs.unc.edu (ARPA,SURA,NSF etc. internet)
tel. (919)-962-6501