Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: comp.dcom.modems
Subject: Re: hayes 9600 vs. trailblazer
Message-ID: <4435@hoptoad.uucp>
Date: 16 Apr 88 05:57:47 GMT
References: <8804110136.AA16978@ucbvax.Berkeley.EDU> <15612@onfcanim.UUCP> <280@telebit.UUCP>
Organization: Grasshopper Group in San Francisco
Lines: 31

rls@telebit.UUCP (Sr. Systems Engineer) wrote:
> 1.  The Telebit TrailBlazer uses Lempel-Ziv data compression, when the S110
>     register is set appropriately.

Note that it does 12-bit compression, which is 5-10% worse than the 16
bit compression common on machines with lots of RAM.

> 2b. When a compression algorithm tries to operate on a random (such as binary,
>     or executable) file, it will lose...

LZ compression actually works pretty well on the average machine
language file.  Certainly ARC and Unix "compress" get a good
compression, though not as good as text.  Stripping /vmunix and
compressing it on my Sun-3/160 resulted in a 38.44% compression savings
(on a 500K file, or 188K saved).  Compressing it with 12 bits, like the
modem would, gives 28.44%.

>     Now, if we compress in the computer, we can send the COMPRESSED output out
>     at 19.2K...			   But if we did compression in the
>     modem, we'd always be limited by the link speed to 19.2K. OK?

It's sad but true that the bottleneck in sending ASCII data between
systems through a Telebit modem is getting to be the 19200 max speed on
the serial cable.  Telebit really should support 38,400 baud.

Jerry Aguirre mentioned that compressing data on the host burns less
CPU cycles too; this would be because running "compress" over say 500K
of data is cheaper than squirting 188K (the data saved) out the serial
port.  The inner loop of compress must be a *lot* smaller than the
inner loop of the serial drivers on his system, though this might not
be true on all systems.