Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!pollux.usc.edu!kjh
From: kjh@pollux.usc.edu (Kenneth J. Hendrickson)
Newsgroups: comp.dcom.modems
Subject: Re: Compression on Text Files
Message-ID: <28557@usc>
Date: 1 Dec 90 21:46:58 GMT
References: <696@nih-csl.nih.gov>
Sender: news@usc
Organization: EE-Systems, USC, Los Angeles
Lines: 38
Nntp-Posting-Host: pollux.usc.edu

In article <696@nih-csl.nih.gov> bert@helix.nih.gov (Bert Tyler) writes:
>> 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!
>
>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?

I don't know about the modem at the other end, but my modem was set up
at both 9600 bps and 19200 bps for these tests.  The results were the
same for both computer<->modem rates.  This probably indicates that the
connection at the other end was at 9600 bps.

The compression used was MNP5, since the modem at the other end doesn't
have V.42bis.

What bothers me the most about this modem is that it doesn't work at all
at bit rates <= 2400 bps.  This is on clean local lines that another
modem (Avatex 2400) has absolutely no problem with.  Since there are
many modems out there at <= 2400 bps, and many systems without >= 9600
bps modems yet, this is unacceptable.

I am currently using the modem at 9600 bps to read the news, and
construct this reply.  It works reasonably well at 9600 bps.  Still,
it's not acceptable, cuz it won't work at <= 2400 bps.

("This modem" is a Practical Peripherals PM9600SA rev. 1.05)

-- 
favourite oxymorons:   student athlete, military justice, mercy killing
Ken Hendrickson N8DGN/6       kjh@usc.edu      ...!uunet!usc!pollux!kjh