Newsgroups: comp.dcom.modems
Path: utzoo!utgpu!cunews!hobbit.gandalf.ca!dcarr
From: dcarr@hobbit.gandalf.ca (Dave Carr)
Subject: Re: Uses of V.42 (bis?) data compression
Message-ID: <1991Apr9.191229.8118@hobbit.gandalf.ca>
Organization: Gandalf Data Ltd.
References: <10334@pitt.UUCP>
Distribution: na
Date: Tue, 9 Apr 1991 19:12:29 GMT
Lines: 62

In <10334@pitt.UUCP> jonathan@cs.pitt.edu (Jonathan Eunice) writes:

>A few questions about V.42 data compresssion (or is is V.42bis? I can't
>keep track):

>1. If one has V.42 compression, with 4:1 compression ratios claimed
>   (and, apparently, ratios rivaling compress/LWZ achieved), does it

One would hope the compression ratios are similar, since the basis for
V.42 bis data compression is LZW.  The main differences are:

(1) When the compressor table becomes full, V.42 bis recovers nodes
    in the compression dictionary one at a time as needed.  Compress
    waits for the compression ratio to drop.

(2) V.42 bis can control EXPANSION.  When the modem detects uncompressable
    data, it can switch into transparent mode, and then switch back
    when the data again compresses.  Unix Compress has no such feature. 

(3) The size of the compression tables may be much smaller in modems.
    Typically, Unix compress uses up to 16-bit codes, while modems MAY
    suuport only 12-bit codes.

>   still make sense to compress data before sending it over the wire?
>   I'd think not--just let the modem h/w do the work.

In fact, the modem may do a BETTER job.  
You may find that there is a quite a difference in the compression
ratio between different V.42 bis modems.  The algorithm for encoding
and decoding are standardized, but the decision to escape to/from
transparent mode is not.

>2. Would it be possible for the modem to hand the system data that is
>   still V.42 compressed?  

Yes, it possible.  Although it would be preferrable if the host-modem
interface was bit-synchronous, since the data may not be an integral
number of octets.

>   Software for online
>   V.42 compression/decompression shouldn't be any harder to develop
>   than compress, right?  And if there were lots of V.42 modems around,
>   which seems to be increasingly the case, V.42 might become a second
>   de facto standard in addition to today's compress.

Sure, just pay the ~$50,000 licensing fees, and away you go.

>3. If #2 is OK, could the system use a modem as a jury-rigged
>   compression/decompression engine?  While perhaps not as good as
>   dedicated h/w, most systems don't use their modems 100% of the time,
>   so it could be a cheap alternative that wouldn't load the system
>   down.  Of course, if the modem were busy when someone wanted to
>   compress/decompress, software emulation could be transparently
>   substituted.

Well, depending on the processor load to handle the I/O, it might be
cheaper to just do the compression in the main system.  LZW encoding
is fairly fast after all, it was design for disk subsystem.

>So, am I in deep left field, or what?

I don't know.  Is there a short-stop between you and the plate ?
