Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!think!snorkelwacker!apple!vsi1!lmb
From: lmb@vicom.com (Larry Blair)
Newsgroups: comp.dcom.modems
Subject: Re: poor uucp performance - help! (LONG)
Message-ID: <1990Feb23.184814.18205@vicom.com>
Date: 23 Feb 90 18:48:14 GMT
References: <125@cdss.UUCP> <1990Feb17.063412.18455@rancho.uucp> <959@codonics.COM>
Organization: Vicom Systems Inc., Fremont, CA
Lines: 23

In article <959@codonics.COM> bret@codonics.COM (Bret Orsburn) writes:
=In article <1990Feb17.063412.18455@rancho.uucp> rock@rancho.uucp (Rock Kent) writes:
=>
=>4.  Make sure that you have compression turned off.  You don't want to
=>    be compressing already compressed news batches.
=>
=
=OK, I'll bite: Why not?
=
=Surely, compression will be less effective the second time, but is there
=any good reason to disable it? Do you have any data to demonstrate that
=throughput is *decreased* by enabling compression for a compressed newsfeed?

L-Z compression will result not result in a smaller size if is the data random,
which is exactly what the compressed output is.  You want proof?  Try
compressing a file and then compress the compressed output.

The TB only does 12 bit compression vs. the 16 bit on the host.  In addition,
the time spent compressing the data is less than the time spend processing
the additional interrupts and tramsmitting the additional data.  No matter
how much the TB can compress, it is still limited to 19200 in and out.
-- 
Larry Blair   ames!vsi1!lmb   lmb@vicom.com