Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!prls!pyramid!hplabs!oliveb!jerry
From: jerry@oliveb.UUCP (Jerry Aguirre)
Newsgroups: net.news,net.mail
Subject: Re: Data compression to lower phone bills
Message-ID: <890@oliveb.UUCP>
Date: Fri, 30-May-86 20:11:35 EDT
Article-I.D.: oliveb.890
Posted: Fri May 30 20:11:35 1986
Date-Received: Sun, 1-Jun-86 07:15:26 EDT
References: <2519@columbia.UUCP> <327@spdcc.UUCP>
Reply-To: jerry@oliveb.UUCP (Jerry Aguirre)
Organization: Olivetti ATC; Cupertino, Ca
Lines: 51
Keywords: data compression
Xref: linus net.news:4091 net.mail:1552
Summary: Data compression REDUCES cpu overhead

I think that those people who are not using compress because of the
additional CPU overhead are not considering the entire picture.  Yes, it
takes cpu cycles to compress a batch of news.  But remember, by making
the batches smaller you save overhead in queueing and transmitting the
batch.  Here are some timings run on a medium loaded Vax750 running
4.2BSD.  The input file is a normal batch of news, compress is version 4.

First test is with two uncompressed batches of 50K
       12.5 real         1.7 user         1.7 sys  batch 50K
       13.5 real         2.7 user         2.0 sys  uux (copy and queue)
       15.7 real         1.8 user         2.2 sys  batch 50K
       16.6 real         2.9 user         2.2 sys  uux (copy and queue)
     1012.3 real        10.1 user        20.2 sys  uucico (2x50K)
			----             ----
			19.2		 28.3 = 47.5 cpu seconds

Second test is with a single compressed batch of 100K
       45.3 real         2.8 user         3.5 sys  batch 100K
       46.1 real         9.5 user         3.2 sys  compress 100K->50K
       46.3 real         2.4 user         2.5 sys  uux (copy and queue)
      508.3 real         6.2 user        12.5 sys  uucico (50K)
			----             ----
			20.9		 21.7 = 42.6 cpu seconds

These timings are of course subject to a lot of variation for different
hardware and different versions of uucp.  But in this configuration
where cpu cycles are at a premium it actually works out to be better to
compress than not!  The actual difference is probably much better as
some of that extra uucico activity consists of DH interrupts that are
probably not being charged to the uucico process.  Also the compress
process can easily be "niced" while using nice on the uucico process
will cause problems.

Older versions of compress would run lots faster if given a smaller
number of bits.  I ran some timing tests on version 4.0 and while it
seems optimized for either 12 or 16 bits the difference in cpu usage
between the two is negligible.  If you are concerned about memory
usage then I suggest you use 12 bits.  The difference in output file
size between using 12 and 16 bits of compression is only about 6
percent.  I would also urge upgrading to version 4.0 as it is
significantly faster than older versions.

In terms of system memory usage the 46 seconds of compress memory usage
can be traded off against the extra 504 seconds of uucico memory
usage.

So, you can have your cake and eat it.  Smaller queues, reduced phone
usage, and LESS cpu cycles.

					Jerry Aguirre @ Olivetti ATC
{hplabs|fortune|idi|ihnp4|tolerant|allegra|glacier|olhqma}!oliveb!jerry