Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!hayes!tnixon
From: tnixon@hayes.uucp
Newsgroups: comp.dcom.modems
Subject: Re: Uses of V.42 (bis?) data compression
Message-ID: <3908.280363d4@hayes.uucp>
Date: 10 Apr 91 19:13:24 GMT
References: <10334@pitt.UUCP>
Organization: Hayes Microcomputer Products, Norcross, GA
Lines: 48

In article <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):

V.42bis is data compression which runs on top of V.42 error control.

> 1. If one has V.42 compression, with 4:1 compression ratios claimed
>    (and, apparently, ratios rivaling compress/LWZ achieved), does it
>    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.

I always advise people to compress before sending if possible.  An 
offline compression program can make multiple passes over the data 
and really optimize the compression, while a modem only has one shot 
at it.  Also, the compression acheivable in the modem is limited by 
the ratio between the DTE-DCE speed and the carrier speed.  
Modem-based compression is great for online text-based applications, 
but if you're sending files and have some control over the process, 
offline compression is better.

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

There's no way for a _standard_ V.42 modem to pass the compressed 
data to the PC.  You wouldn't really want to, anyway -- there's no 
way to delimit the file boundaries, etc.  While I suppose some 
manufacturer could produce a proprietary feature to allow the 
compressed data to be passed to the software, I doubt it would ever 
become part of the standard.

> 3. If #2 is OK, could the system use a modem as a jury-rigged
>    compression/decompression engine?  

Again, perhaps some manufacturer will develop this as a proprietary 
feature, but it won't become part of a standard.

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

No, these things have been thought about before, but the standards 
community didn't think it was feasible or reasonable.

-- 
Toby Nixon, Principal Engineer    | Voice   +1-404-840-9200  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