[net.dcom] interactive

jqj@cornell.UUCP (J Q Johnson) (09/26/85)

People using a terminal emulator on home computer with a modem soon
find that 1200b or 2400b isn't all that fast.  In principal, effective
data rates for typical interactive terminal sessions could be improved
by at least a factor of 2 or 3 using data compression techniques.

Does anyone have software for such host=>terminal data compression?
Easy static techniques exist for 20% to 50% improvements; can we do
better?  Note that in addition to being self-synchronizing or reliable
(to cope with modem transmission failures) any such technique must not
be too costly to either encode or decode.  Note also that various
vendors have quite efficent proprietary implementations.

My particular environment is a 4.xBSD host and an ATT 3b2 (sys V) or
IBM PC (running DOS or Xenix) client, talking at 1200b asynch 7 bit
with XON/XOFF.  Ideally I'd like public domain code that supports at
least one of these environments.  Failing that, pointers to algorithms
or publicly available implementations for other environments would also
be appreciated.

Given sufficient feedback, I will of course summarize.

cornell!jqj		UUCP
jqj@cornell.arpa	Internet

nazgul@apollo.uucp (Kee Hinckley) (10/02/85)

It is my belief that some of the new 4800 baud modems under development
do this internally (that is, they are actually 2400 baud + data
compression).  It would be interesting if that technology trickled
down to the 1200 baud modems, but of course you'll have to buy a
new modem...


                                        -kee
                                        
                                        ...decvax!wanginst!apollo!nazgul

jqj@cornell.UUCP (J Q Johnson) (10/03/85)

In article <294a86e4.8e4@apollo.uucp> nazgul@apollo.uucp (Kee Hinckley) writes:
>It is my belief that some of the new 4800 baud modems under development
>do this internally (that is, they are actually 2400 baud + data
>compression).  It would be interesting if that technology trickled
>down to the 1200 baud modems, but of course you'll have to buy a
>new modem...
No, you'll have to buy at least *2* new modems, and probably n > k where
k is the number of modems in your modem pool on the host.  Switching to
a new modem protocol can be very expensive!  One solution is an outboard
data compression box that you can add on, but box+modem is probably still
a lot more expensive than an integrated solution.

The advantage of doing it in software, at least on the client end, is
that you already have this overpowerd PC sitting there waiting to be used.
Presumably, the PC can also be a lot smarter about its compression algorithm
than could an inexpensive modem.

lauren@vortex.UUCP (Lauren Weinstein) (10/04/85)

I was involved in work in this area some years ago.  In practice, don't
expect more than about 30-40% compresson on typical text--this goes
WAY down if you try to run display editors over such circuits due to
the large number of control characters that greatly disrupt the
"text" aspects of the compression.  There are a variety of synchronization
problems to deal with, and for best results the host must have the
compresson code buried WITHIN the tty driver itself.

--Lauren--

steved@athena.UUCP (Steve Dum) (10/08/85)

>>I was involved in work in this area some years ago.  In practice, don't
>>expect more than about 30-40% compresson on typical text--this goes
>> ...
>>--Lauren--

I know of one company now selling compression boxes that go on each end of
the data line before the modem that are managing compression rations of
2.5 to one for typical text.  Here typical means things like c program 
source, man pages or prose.  I haven't seen any data for what their algorithm
might do for edit sessions.  However if the edit session is highly interactive
most of the time is due to turnaround rather than baud rate.  

I believe they sell a z80 based black box for under $1000.  Its from
Adaptive Computer Technology 408-279-3993.

lauren@vortex.UUCP (10/09/85)

The very best compression systems in general use (like "compress")
still achieve less than 50% compression for typical text.  Of course,
if you select the text carefully for your statistics, you can seem
to do much better.  Display editors and other programs that fiddle
with cursor addressing sequences and such can really screw up
compression program effectiveness, by the way.

--Lauren--