Path: utzoo!utgpu!water!watmath!clyde!rutgers!uwvax!oddjob!gargoyle!ihnp4!ih1ap!jfs
From: jfs@ih1ap.ATT.COM (J.F. Shumway)
Newsgroups: comp.dcom.modems
Subject: Re: MNP make for a faster modem?
Keywords: MNP
Message-ID: <959@ih1ap.ATT.COM>
Date: 27 Jan 88 05:12:51 GMT
References: <3027@killer.UUCP> <6678@agate.BERKELEY.EDU> <6701@agate.BERKELEY.EDU>
Reply-To: jfs@ih1ap.UUCP (J.F. Shumway)
Organization: AT&T-Network Systems
Lines: 30

In article <6701@agate.BERKELEY.EDU> chapman@eris.UUCP (Brent Chapman) writes:
>I've been informed that higher levels of MNP include compression as well as
>error detection and correction.  Even so, I find a 4 to 1 compression ratio
>hard to believe under any "real" conditions, especially in interactive use.

Yes, it is hard to beleive, indeed.

>The "compress" program, which is pretty good according to the people I know
>who know about such things (I don't), rarely manages a 4:1 ratio, and then
>only on large, fairly repetitious files; I doubt the ability of any modem
>to do much better, because it can't use _too_ large a "block size" for
>compression because of response time considerations.  [I'd be happy to
>be shown to be wrong, however...]

Yer right. Compression in the higher level MNP protocols is done by
simple run length encoding. A string of several identical 
characters in a row are encoded as the character and the length of
the sequence. This may be a win if your data is, say, blank (\040)
padded into 80-80 card images for shipment to some IBM dinosaur,
but it doesn't gain you much in a Unix environment. 

The compress program you mention uses the Lempel-Ziev (sp?)
adaptive Huffman encoding compression alogorithm. I understand that
LZ compression is performed by the Telebit Trailblazer in its
intermodem packets when emulating the uucp "g" protocol.

-- 

Jesse Fred Shumway	
ihnp4!ih1ap!jfs