Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!julius.cs.uiuc.edu!zaphod.mps.ohio-state.edu!caen!uflorida!haven!adm!lhc!nih-csl!helix.nih.gov
From: bert@helix.nih.gov (Bert Tyler)
Newsgroups: comp.dcom.modems
Subject: Compression on Text Files
Message-ID: <696@nih-csl.nih.gov>
Date: 1 Dec 90 13:47:52 GMT
Sender: news@nih-csl.nih.gov
Organization: National Institutes of Health, Bethesda
Lines: 28

> Initially, I was very pleased.  It was plug and play.  It supports V.32,
> V.42, V.42bis, MNP2-4, and MNP5.  I had no difficulty at all dialing up
> the University's V.32 modems (MNP5).  9600 bps was sure a lot nicer than
> 2400 bps.  I played with the registers allowing Data Compression and
> Error Correction.  I found that _disallowing_ Data Compression yielded
> higher data transfer rates!  This was true both for compressed files
> (.ZIP) and for text files.  This was suprising, especially in the case
> of text files.
> ...
> Conclusions:
>
> Disallow Data Compression for higher data transfer rates,
>        on ALL types of files!

Data compression on text files works fine for me and everybody else I
have heard from.  It sounds like something was wrong with your setup
or modem.  Did you have your modem <-> PC connection set at a higher
connect rate than 9600 bps (say, 19200 or 38400)?  Was the modem on the
other end set up the same way?  If *either* of the modems is connected
to its computer at 9600 bps, then there is no way that they will be able
to transfer information at a data rate faster than 9600bps, and in fact
the extra overhead of both handling modem<->modem data compression and
constantly telling the modem on the other end to slow down *could* lower
your effective transfer rate.

Think of it as pumping water through a series of pipes - the final flow
rate is going to be determined by (among other things, I know) the 
smallest section of pipe in the sequence.