Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!hayes!tnixon
From: tnixon@hayes.uucp
Newsgroups: comp.dcom.modems
Subject: Re: Flow control in modems
Message-ID: <3775.27b7e753@hayes.uucp>
Date: 12 Feb 91 13:02:11 GMT
References: <1991Feb2.173201.24760@PacBell.COM> <3765.27aaf09a@hayes.uucp> <1991Feb11.145217.17047@bigsur.uucp>
Organization: Hayes Microcomputer Products, Norcross, GA
Lines: 46

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