tnixon@hayes.uucp (02/03/91)
In article <1991Feb2.173201.24760@PacBell.COM>, sxmirch@PacBell.COM (Sonu Mirchandani) writes: > I am looking for a modem that operates full duplex, and can > support flow control (RTS/CTS, XON/XOFF - optionable) to and > from the DTE. > ... > That leaves the hardware flow control option - RTS/CTS. > This option is for regulating the modem Receive Buffer (Rx > data from the DTE) by lowering or raising CTS. So that leaves > me without the ability for the DTE to limit data coming into > its Receive Buffer from the modem. All modems I'm aware of that support RTS/CTS flow control support it in both directions -- the modem can drop CTS to tell the DTE to suspend sending data to the modem, and the DTE can drop RTS to tell the modem to suspend sending data to the DTE. The use of the signal appearing on pin 4 of an EIA-232 interface in this manner is not really consistent with the definition of RTS, but people tend to call it "RTS/CTS" anyway. In V.42, however, it is called what it really IS -- "RTR/CTS" or "133/106" flow control, where "RTR" means "Ready To Receive". This alternative use of pin 4 is included in EIA-232-E (which is out for ballot right now), and has been defined in CCITT V.24 for a long time. Did you not understand this use of RTS to be the case, or is there some other problem you're having that I don't understand? -- Toby Nixon, Principal Engineer | Voice +1-404-449-8791 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 hayes!tnixon@uunet.uu.net
ch@dce.ie (Charles Bryant) (02/04/91)
In article <3765.27aaf09a@hayes.uucp> tnixon@hayes.uucp writes: >All modems I'm aware of that support RTS/CTS flow control support it >in both directions -- the modem can drop CTS to tell the DTE to >suspend sending data to the modem, and the DTE can drop RTS to tell >the modem to suspend sending data to the DTE. As far as I am aware that is true for new modems, but the original software in the Quattro (an Octocom/Steebeck/Dowty modem popular in the UK) used CTS but not RTS for flow control. That was the revision before MNP (it had some other error correction scheme). It is obviously essential that CTS is available for flow control when error correction is used, but RTS is only for the convenience of the DTE (though I would consider it important). -- Charles Bryant (ch@dce.ie) -- /usr/ch/.signature: Block device required
crm57d@bcars53.uucp (Ken Hayward) (02/11/91)
In article <3765.27aaf09a@hayes.uucp> tnixon@hayes.uucp describes
how rts/cts operate on asyn data for a V.32/v.42(bis) modem. I'd like to
ask whether anything equivalent happens for synchronous traffic using
the same modems, i.e., can I have a 'nominal' DTE/DCE line speed of 38.4
kbit/s and have the modem do error control and data compression, or should
I turn off error correction (since the sync protocol does this)? And is
flow control between the modem and DTE still done using CTS/RTR?
Or is all of this nonsense, and I'm stuck at 9.6 kbit/s (or whatever
the 'real' line speed is)?
Thank you.
--
-------------------------------------------------------------------------------
Ken Hayward |Bitnet: crm57d@bnr.ca | Phone: (613) 763-4042
BNR Ltd. | UUCP: ..uunet!bnrgate!bcars267!crm57d| FAX: (613) 763-2626tnixon@hayes.uucp (02/12/91)
In article <1991Feb11.145217.17047@bigsur.uucp>, crm57d@bcars53.uucp (Ken Hayward) writes: > In article <3765.27aaf09a@hayes.uucp> tnixon@hayes.uucp describes > how rts/cts operate on asyn data for a V.32/v.42(bis) modem. I'd like to > ask whether anything equivalent happens for synchronous traffic using > the same modems, i.e., can I have a 'nominal' DTE/DCE line speed of 38.4 > kbit/s and have the modem do error control and data compression, or should > I turn off error correction (since the sync protocol does this)? And is > flow control between the modem and DTE still done using CTS/RTR? > > Or is all of this nonsense, and I'm stuck at 9.6 kbit/s (or whatever > the 'real' line speed is)? When operating in synchronous mode, all modems I know of today don't have error control or data compression active, since the DTEs always have a protocol of their own. Therefore, there's no need to have flow control between the DTE and DCE -- and, indeed, most synchronous DTEs wouldn't know what to do with it if you did drop CTS (most would actually assume that the line had failed and disconnect the call). In most synchronous implementations, RTS and CTS are used in their "traditional" sense of turning around the carrier in half-duplex modems, rather than the "new" interpretation as flow control that is used in async error control applications. So, yes, you're "stuck" with the native throughput of the modem. However, CCITT Study Group XVII is presently studying the use of V.42bis data compression on SYNCHRONOUS traffic. This would involve taking the synchronous data stream, encoding it into octets in some fashion, passing it through a V.42bis compressor, transporting it on V.42 error control, and undoing it all at the other end. There are a lot of complications -- such as handling idle periods, time filing at the receiver during retransmissions (stop the receive clock?), flow control at the transmitter during retransmissions (stop the transmit clock?), minimizing propagation delay (since most DTE-DTE sync protocols are quite timing-sensitive), etc. I won't make any predictions on when or if such a capability will ever be standardized. -- Toby -- Toby Nixon, Principal Engineer | Voice +1-404-449-8791 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 hayes!tnixon@uunet.uu.net