HAL/MISSLINKS/MikeB%Traveling_Software;_Inc.@MCIMAIL.COM (MikeB) (06/20/91)
I'm curious how exactly the RTS/CTS handshaking flow control works between a PC and a modem. From what I've seen the following is true: o The CTS is asserted when the modem buffer is full (256 bytes?). o If a PC asserts RTS, it causes the *remote* modem to stop sending data although a few bytes still get through. o There is no way to signal the local modem to stop sending data. Are these statements true in general? Are there modems that do the RTS/CTS handshaking differently? Why is RTS implemented that way? For a programmer writing a modem interface protocol, what is the best to way to handle hardware flow control? I anxiously await any responses...
tnixon@hayes.uucp (06/21/91)
In article <42910619180524.0004025717NB2EM@mcimail.com>, HAL/MISSLINKS/MikeB%Traveling_Software;_Inc.@MCIMAIL.COM (MikeB) writes: > I'm curious how exactly the RTS/CTS handshaking flow control works between a > PC and a modem. From what I've seen the following is true: > > o The CTS is asserted when the modem buffer is full (256 bytes?). CTS is normally high -- after all, it stands for "Clear to Send". When the modem buffer fills past a certain point (usually 75%, not completely full, to allow some time for the PC to react to the change in state), the modem drops CTS. Then, when the buffer empties to a certain point (usually 25%; you never use the same "on" and "off" point, or the signal would be constantly bouncing up and down), CTS is reasserted, allowing data to flow once again. As for the buffer size itself, this varies widely from manufacturer to manufacturer. Hayes uses 256-byte buffers on the DTE (PC) interface, in order to avoid having large amounts of data buffered up in one modem that can't be effectively stopped by a cancel request from the other DTE. Other manufacturers have used much larger buffers, on the theory that this makes it more possible for them to support DTEs that don't properly support flow control (but, in that situation, you WILL, sometime, lose data anyway!) > o If a PC asserts RTS, it causes the *remote* modem to stop sending data > although a few bytes still get through. "RTS" is a misnomer in this case. It is called that only because the function being performed by the signal is assigned to the same pin as the RTS (Request to Send) signal. But when the pin is being used for flow control, it is more properly known as RFR (Ready for Receiving). The signal, again, is normally on. When the PC's buffer fills to a certain point (I won't repeat the discussion above, but the details of on/off points are the same), it drops RFR. This stops the LOCAL MODEM from delivering more data to the PC. In most modems, there is NO direct transfer of this signal to the remote modem. Instead, what happens is that the stoppage of flow to the local PC causes data to build up the local modem's buffers. When those buffers reach a certain point, the local modem signals the remote modem through a particular frame in the error control protocl (RNR [Receive Not Ready] in LAPM), which stops more data from coming across the phone line. The remote DTE may still be delivering data to the remote modem, so when the remote modem's buffers fill to a certain point, it stops flow from the remote DTE (either by sending XOFF or dropping CTS, depending on which form of flow control is being used). So, yes, by dropping RTS, the local DTE can _eventually_ stop the flow of data from the remote modem and DTE, but it is all the buffers in the receive path becoming full rather than any immediate transfer of flow control status to the remote. I should note that SOME modems DO flow off the remote modem with RNR as soon as the local DTE drops RFR, but that is not generally considered to be the most efficient way to manage the link. > o There is no way to signal the local modem to stop sending data. Sure there is, as I described above. > For a programmer > writing a modem interface protocol, what is the best to way to handle > hardware flow control? As I stated above. When CTS changes state (on or off), you should get a Modem Status Change interrupt. If CTS has gone off, you should suspend data transmission (completing any character already in the process of being sent or already in UART buffer). When CTS goes back on, resume data transmission. On the receive side, when your receive buffer fills to a particular point (say, 75% of full), drop RTS to cause the modem to suspend delivering data, and when it gets down to a lower point (say, 25%), reassert RTS to cause the modem to resume delivering data to you. -- Toby -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet tnixon%hayes@uunet.uu.net
gordon@sneaky.lonestar.org (Gordon Burditt) (06/22/91)
You are describing one method of hardware flow control that provides flow control in both directions. There are other methods, incompatible, of course. >o The CTS is asserted when the modem buffer is full (256 bytes?). Depending on your definition of "asserted", I thought CTS was asserted to indicate the terminal/computer should send, and de-asserted to indicate it should not. The CTS should be asserted when the modem buffer is ALMOST full. 80-90% is a nice number. The size of the modem buffer is up to the modem manufacturer. Some use at least 2k. The modem should give some advance notice to stop sending. It is impossible to design a stop-on-a-dime flow control scheme using serial transmission. For one thing, a serial port can't stop transmitting in the middle of a character, so at least one character is likely to arrive after CTS drops. In many cases, the system may not be able to "take back" another character already fed to a UART and buffered by it. Don't be at all surprised at 2-3 characters arriving after dropping CTS. >o If a PC asserts RTS, it causes the *remote* modem to stop sending data >although a few bytes still get through. There is no communication channel for a local modem to tell a remote modem to quit sending in many modem protocols, including non-MNP 2400, 1200, and 300 baud (we're not talking about control-S/control-Q). The local modem quits sending. The local modem's buffers fill up. If possible, the local modem tells the remote modem to quit sending. This is possible in PEP, MNP4 and above, and probably any other protocol with error control. The remote modem's buffers fill up. The remote modem tells the computer to quit sending, assuming it's using flow control. Flow control need not even involve a remote modem. Ask a modem for a several complete sets of parameter settings, and it's likely to dump out enough data that a system can't take it at a full 19.2kbps. >o There is no way to signal the local modem to stop sending data. There is no way to have absolute stop-in-an-instant flow control. However, assuming proper setup, RTS will stop the local modem from sending. Gordon L. Burditt sneaky.lonestar.org!gordon
root@zswamp.uucp (Geoffrey Welsh) (06/22/91)
In a letter to All, MikeB (HAL/MISSLINKS/MikeB%Traveling_Software;_Inc.@MCIMAIL.COM ) wrote: >I'm curious how exactly the RTS/CTS handshaking flow control >works between a PC and a modem. From what I've seen the >following is true: >o The CTS is asserted when the modem buffer is full >(256 bytes?). >o If a PC asserts RTS, it causes the *remote* modem to stop >sending data >although a few bytes still get through. >o There is no way to signal the local modem to stop sending >data. You seem to have inverted the idea of "asserted". The host may transmit to the modem as long as the modem has CTS asserted; when it does so is up to its firmware, but a buffer nearing full is a perfect example of a really good reason. The modem may transmit to the host as long as the host has RTS asserted; full buffer is again a good reason to de-assert RTS. In either case the other end can be expected to send a couple more bytes before noticing the handshaking lines (though I suspect that the better coded modems will send no more than one byte). If you're using an error correcting protocol between the modems, it should also support signalling between modems. Overall example: fast computer sending compressed data to a V.32 modem at 19,200 bps; slow computer (e.g. 4.77 MHz XT <grin>) receiving from a V.32 modem at 19,200 bps (with the aid of a 16550), and the protocol is a streamer (ZMODEM, YMODEM-G, UUCP-e, etc.) When the XT's buffer is full, it drops RTS, causing the local modem stops transmitting. When its internal buffers are full, it indicates to the remote modem not to send any more data packets. When the remote modem's buffer is full, it will de-assert CTS, causing the serial driver on the sending computer to stop transmitting. Nifty, eh? Note that some of the more advanced modems implement some form of flow control, even when not in error correction mode; they send an XOFF over the phone line in the hopes that the other end understands. I usually don't use this method, since I always use error correcting protocols at speeds above 2400. >Why is RTS implemented that way? Because someone tried it that way, it worked, and others did likewise. -- Geoffrey Welsh - Operator, Izot's Swamp BBS (FidoNet 1:221/171) root@zswamp.uucp or ..uunet!watmath!xenitec!zswamp!root 602-66 Mooregate Crescent, Kitchener, ON, N2M 5E6 Canada (519)741-9553 "He who claims to know everything can't possibly know much" -me
jeh@cmkrnl.uucp (06/23/91)
In article <42910619180524. 0004025717NB2EM@mcimail.com>, HAL/MISSLINKS/MikeB%Traveling_Software;_Inc.@MCIMAIL.COM (MikeB) writes: > I'm curious how exactly the RTS/CTS handshaking flow control works between a > PC and a modem. From what I've seen the following is true: > > o The CTS is asserted when the modem buffer is full um, depends on what you mean by "asserted". To many people "asserted" means "actively driven to one state or the other, as opposed to simply floating free", without specifying *which* state it's driven to. Lets use the terms "drives the signal true" or "drives the signal false", or just "raises" and "drops", instead of "asserts". Anyway, when the modem wants datam, it drives the CTS signal true, and when its outgoing buffer is full, it drives the CTS signal false. The PC is expected to send and not send data, respectively. > (256 bytes?). the size of the buffer is dependent upon the modem. > o If a PC asserts RTS, it causes the *remote* modem to stop sending data > although a few bytes still get through. no. RTS controls the *local* modem. When the local modem sees RTS go false, it stops sending data to the PC; when RTS is true, the local modem sends data to the PC. The PC drives RTS true or false when it wants, or does not want, data, respectively. > o There is no way to signal the local modem to stop sending data. No. Just the opposite; there is no (direct) way to signal the *remote* modem to stop sending data. There is no provision for passing modem-control signals "through the link" to the remote modem. Modem-control signals, by definition, control the local modem. However, on an error-corrected link such as V.42 or PEP, and assuming that both ends' modems and hosts are using full-duplex RTS/CTS flow control, what will happen is: 1. The local system's buffer fills up and it sets RTS false. 2. The local modem stops sending data to the local system. 3. The modem's received-data buffer fills up, since it has no place to dump the data, so the modem stops sending ACKs to the remote (sending) modem, or it stops sending send credits, or it sends a "send no more data" signal, or whatever is appropriate for the protocol in use. 4. In response to the lack of ACKs, or whatever, the remote modem stops sending data to the local modem. 5. The remote system keeps sending, but the remote modem doesn't, so the remote modem's send-data buffer fills up, and... 6. ...the remote modem sets CTS false, causing the remote system to stop sending data to the remote modem. At this point all traffic has stopped, but there is a bunch of data in both modems' buffers, data that was sent sometime later than the time that the local system dropped RTS. As soon as the local system raises RTS, the local modem starts sending data to the local system again. Soon the local modem's buffer is less full and its flow control mechanism tells the remote modem to resume sending. Soon the remote modem's buffer is less full, and the remote modem raises CTS to tell the remote system to resume sending. But the local system's RTS signal is *not* passed directly to the remote modem. If there is no flow control protocol in effect between the two modems, the local system's RTS signal will not even have a delayed effect on the remote modem or the remote system. (Implication: If you're not using a protocol such as V.42 that does flow control between the modems, two statements can be made about RTS/CTS : 1. RTS flow control will not help you avoid losing data. It may help you avoid buffer overruns in your local host but data can still be lost elsewhere. 2. CTS flow control can still be used for those cases where your link speed is slower than the host-to-modem speed and you want to avoid overrunning the local modem's buffer, but that is the only thing it will do for you; it will not tell you whether you're overrunning either the remote modem's receive buffer or the remote host's buffer. ) Clear now??? I will also note in passing that the signal on pin 4, when used as part of "RTS/CTS flow control", is properly called "Ready To Receive (RTR)" rather than Request To Send. When the DCE (modem) uses pin 4 for RTR, it assumes that RTS is always true. This is according to the latest version of EIA-232, EIA-232-E. (Thanks to Toby Nixon of Hayes Communications for this info, and for his work on the relevant standards committee!) --- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA Chair, VMS Internals Working Group, U.S. DECUS VAX Systems SIG Internet: jeh@dcs.simpact.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!cmkrnl!jeh