Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!netcomsv!gandrews
From: gandrews@netcom.COM (Greg Andrews)
Newsgroups: comp.dcom.modems
Subject: Re: Hardware flow control and Compression
Summary: Compression doesn't require hardware flow control.  Transparency does.
Keywords: compression, flow control, v.42bis
Message-ID: <1991May21.060606.12846@netcom.COM>
Date: 21 May 91 06:06:06 GMT
References: <49273@ut-emx.uucp>
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
Lines: 70

In article <49273@ut-emx.uucp> csquared@ccwf.cc.utexas.edu (Randy Clarke) writes:
>(A humble request to the net.modem.gurus)
>
>     We're currently trying to set up some v.42bis modems on our Xyplex
>terminal server at work.  The problem we've run into is this:  Apparently,
>compression only works if RTS/CTS flow control is available.  
>

With all the modems that I'm familiar with, that is not true.  Compression
does not require hardware flow control.  Matter of fact, compression doesn't
require ANY flow control, in and of itself.  The real inter-relationship is
a bit different.  To illustrate:

  a) Modem compression requires that data be pumped into the modem faster
     than the modem could pump it out (if compression weren't active).  In
     other words, the RS232 port speed should be faster than the modem-to-
     modem connection speed.  Otherwise, compression wouldn't give you any
     boost in throughput.

  b) Since real world conditions control the data transfer process, some data
     may not be as compressible as other data.  Also, the modems may encounter
     impairments in the phone line.  Both of these conditions may cause the
     modems to transmit data slower than expected.

  c) If the modems can't transmit as fast as expected, they may need to tell
     the computers to pause while the modems 'catch up'.  The method where
     the modems tell the computer to pause is Flow Control.  Flow control is
     NOT required when the port speed is faster than the connection speed,
     but it is STRONGLY recommended.  The modems don't care which method of
     flow control you decide to use - as long as it works.

So you see that compression relies upon a faster RS232 port speed, and a faster
port speed works best with flow control.  However none of those require one
particular method of flow control over another, as long as the chosen method
works correctly with the computer.

However, there is another consideration here.  It is not directly related to
compression, so I didn't include it in my three point summary above.  That
other consideration is Data Transparency.

Data Transparency is the idea that the modems (or any device) will pass your
data through without altering it, and without mis-interpreting it.  Using
XON/XOFF flow control in the modems is not the most transparent mode, because
the modems will place special meaning on the XON and XOFF characters.  If an
XON appears in the middle of your data, the modem will probably swallow it
because the modem was told that XONs and XOFFs are flow control commands and
not data characters.  Imagine what an XOFF character would do.  The modem
will stop returning the other system's data!

If the data that is exchanged between your systems will never pass XON or XOFF
as data, then that's not a problem.  XON and XOFF would appear only as flow
control commands, so it's safe for the modems to react to them as such.
However, if XON or XOFF bytes would appear as part of the data (as they do
in the XMODEM, YMODEM, or UUCP "g" file transfer protocols), then XON/XOFF
flow control will cause trouble.

Hardware flow control has the advantage of leaving the modems in a completely
transparent state.  They don't use characters as start/stop commands, so they
won't mis-interpret any of the data the computers send through them.

To summarize, Compression doesn't *require* hardware flow control, but it's
the recommended way to go.

>       Randal C. Clarke

-- 
 .------------------------------------------------------------------------.
 |  Greg Andrews   |       UUCP: {apple,amdahl,claris}!netcom!gandrews    |
 |                 |   Internet: gandrews@netcom.COM                      |
 `------------------------------------------------------------------------'