Path: utzoo!utgpu!water!watmath!onfcanim!dave
From: dave@onfcanim.UUCP (Dave Martindale)
Newsgroups: comp.dcom.modems
Subject: Re: hayes 9600 vs. trailblazer
Message-ID: <15617@onfcanim.UUCP>
Date: 15 Apr 88 02:44:02 GMT
References: <8804110136.AA16978@ucbvax.Berkeley.EDU> <15612@onfcanim.UUCP> <494@edsews.EDS.COM>
Reply-To: dave@onfcanim.UUCP (Dave Martindale)
Organization: National Film Board / Office national du film, Montreal
Lines: 37

>In article <15612@onfcanim.UUCP>, dave@onfcanim.UUCP (Dave Martindale) writes:
>> 
>> (I know that some modems, including the Trailblazer, can get higher
>> effective throughput by compression.  But news is usually already
>> compressed (it actually saves host CPU time to do the compression
>> on the host) and doing compression in the modem is counterproductive).

which elicited several questions.  Let me clarify:

The UNIX compress program is pretty efficient about its data handling.
It doesn't perform many instructions for each byte of input data.
Uucico is somewhat expensive - it builds a packet header and computes
a CRC for every 64 bytes of data.

Someone did some studies a few years ago and found that, for your average
VAX USENET host and average load of USENET traffic (mostly ASCII text),
it was cheaper in terms of total CPU cycles to compress the news and
then send the smaller files than it was to let uucico send the uncompressed
data.  So, even if you don't care about the increased transmission bandwidth
you get, or the reduction in uucp spool space, you still want to compress
news on the host purely to save host CPU cycles.

Given that your news is compressed, compression in the modem actually
slows things down.  So, I turn off compression (via a chat script in
L-devices) for hosts that send me news, on the assumption that news
is most of the volume of traffic on that link.  For non-news links,
the traffic will be all mail, and compression is on.  You pick whichever
you think is better (on average) on a link-by-link basis.

Not that it matters much on clean phone lines - the raw throughput
of 14000 bps is enough to keep most machines busy servicing their
serial input queues.

Note that for the unfortunate people with Intel-architecture machines,
compress uses a kludge that slows down array addressing considerably,
making compress as a whole much more expensive.  For these people,
compression in the host may not be worthwhile.