Date: Mon, 13 Nov 1995 06:56:22 +0200 From: Heikki Suonsivu <hsu@cs.hut.fi> To: michael butler <imb@scgt.oz.au> Cc: freebsd-current@freefall.FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/pppd RELNOTES Message-ID: <199511130456.GAA15534@shadows.cs.hut.fi> In-Reply-To: michael butler's message of 12 Nov 1995 08:44:25 %2B0200
next in thread | raw e-mail | index | archive | help
> hsu#hauki.clinet.fi Sun 37: time gzip -1 < csh > /dev/null
.. ah .. this is not the default compression method. You should've said :-)
It makes no sense to use maximum compression to gain 1-2% better
compression at cost of 2-3 times longer compression time, at least in
compressing data on tcp/ip links.
For comparison and using the default method on a 386DX/40 also running
-current ..
asstdc:~ % time gzip </bin/csh >/dev/null
9.417u 0.109s 0:10.63 89.4% 100+624k 9+0io 10pf+0w
...
=> mean of ~9.49 user secs.
asstdc:~ % time compress </bin/csh >/dev/null
3.315u 0.108s 0:03.42 99.7% 19+727k 2+0io 1pf+0w
...
=> mean of ~2.982 user secs.
Without the qualification of not using the default method, ZIP is ~300% more
predictor-1 doesn't use default method either, for the same grounds I would
use -1 on gzip. The fact is that zip compression with its best
configuration options is equal in CPU consumption, but better in
compressing, when comparing compress with its best configuration options.
Thus zip algorithm is a superior alternative.
I wouldn't mind allowing better compression levels of zip algorithm as an
option to pppd, though, so that I can configure my links according to the
cpu available (I have a 386-16 routing my home into a 57.6k PPP link,
40%-50% of CPU goes into processing interrupts :-).
--
Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND,
hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511130456.GAA15534>