Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!oliveb!jerry
From: jerry@oliveb.olivetti.com (Jerry Aguirre)
Newsgroups: comp.dcom.modems
Subject: Re: hayes 9600 vs. trailblazer
Message-ID: <19963@oliveb.olivetti.com>
Date: 14 Apr 88 02:23:25 GMT
References: <8804110136.AA16978@ucbvax.Berkeley.EDU> <15612@onfcanim.UUCP> <494@edsews.EDS.COM> <280@telebit.UUCP>
Reply-To: jerry@oliveb.UUCP (Jerry Aguirre)
Organization: Olivetti ATC; Cupertino, Ca
Lines: 41

In article <280@telebit.UUCP> rls@telebit.UUCP ( Sr. Systems Engineer) writes:
>    Now, if we compress in the computer, we can send the COMPRESSED output out
>    at 19.2K. This means the ACTUAL THROUGHPUT would be the 19.2K link speed
>    times the compression ratio. If we use a compression ratio of 1.5:1, then
>    the actual throughput would be 28.6K. But if we did compression in the
>    modem, we'd always be limited by the link speed to 19.2K. OK?

That is an excelent point and I didn't think of it when reading the
article with the question.  However I think that the original statement
about it being more efficient to compress in the host was talking about
cpu overhead, not thruput.  Compressing the data reduces the quantity of
data to be handled by subsequent queueing and IO.  This reduction in IO
overhead (fewer interupts) more than makes up for the overhead used in
compression.  (I actually ran tests to measure this.)  So, you win three
ways, lower CPU overhead, less disk space for the queue, and faster
transfers.

>4.  So the general rule of thumb is, only compress ONCE in the data stream, 
>    either in the hardware (modem) or in the software (computer). Usually, it 
>    will be desireable to compress in the computer, unless the computer cycles
>    are scarce or expensive.

The problem is that the typical UUCP user doesn't have real control over
this.  The queue for a remote site will typically contain a mix of jobs,
news already compressed, file copies possibly compressed, and mail not
compressed.  There is no provision either for indicating which jobs
should be compressed or having uucico switch modem options based on each
call much less each job.

Actually I am curious about what the compression really buys the typical
UUCP user.  The "usable" data rate is 14k which allowing for the sync
to async conversion is pretty close to the 19.2K rate of the interface.
With those parameters compression doesn't seem to have any advantage.
Of course of the connection is poor then the data rate will drop below
the 19.2K interface rate and then compression will be an advantage.
Also a protocol requiring sending data in both directions would also see
an advantage.

Me?  I talk UUCP to the modem at 9600 and all my connections are
"perfect".  Compression in the modem isn't going to help me any.

				Jerry Aguirre