Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!zaphod.mps.ohio-state.edu!van-bc!cynic!curt
From: curt@cynic.wimsey.bc.ca (Curt Sampson)
Newsgroups: comp.dcom.modems
Subject: Re: Using High Speed Modems
Message-ID: <1991May24.095830.180@cynic.wimsey.bc.ca>
Date: 24 May 91 09:58:30 GMT
References: <28675@uflorida.cis.ufl.EDU> <6536@vela.acs.oakland.edu> <1991May23.193607.14738@qualcomm.com>
Distribution: na
Organization: Mad Artists' Technological Hangout
Lines: 31

In article <1991May23.193607.14738@qualcomm.com>
  rdippold@cancun.qualcomm.com (Ron Dippold) writes:

> In article <6536@vela.acs.oakland.edu> rdthomps@vela.acs.oakland.edu (Robert D. Thompson) writes:
> >	Do modems with V.42 compression cause compressed files (e.g.
> >	PKZIP, LHARC, etc...) to become effectively larger when
> >	transferred?  In other words, is there negative compression
> >	when transferring a compressed file via V.42?
> 
> First, V.42 is only error correction, V.42bis is compression.  However, V.42
> is smart enough to realize when the compression is causing the data to expand
> and will send the data un"compressed".

V.42 will "compress" everything by about 15% (by stripping the start
and stop bits), period.  It workes equally well on compressed and
non-compressed files.

If you are using V.42bis compression, it will detect if the
compression is actually increasing trasfer time and will not compress.

If you are using MNP-5 compression, which is quite common with V.42,
it will *increase* transfer time on compressed files, because it does
*not* check to see whether the compression is ineffective or not.
Using V.42 will not help this situation at all.

cjs

-- 
Curt Sampson            | "[Atari's Race Drivin'] is more fun as a perverse
curt@cynic.uucp         | sort of flight simulator than a driving game."
curt@cynic.wimsey.bc.ca |           --Kevin Nomura (chow@netcom.com)