NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/dcom/servers/56

Internet Message Format | 1992-07-26 | 3.5 KB

Xref: sparky comp.dcom.servers:56 comp.dcom.lans.ethernet:1481
Newsgroups: comp.dcom.servers,comp.dcom.lans.ethernet
Path: sparky!uunet!darwin.sura.net!jvnc.net!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!torn!cunews!hobbit.gandalf.ca!dcarr
From: [e-mail] (Dave Carr)
Subject: Re: Microcom B-Routers (TCP/IP)
Message-ID: <[e-mail]>
Organization: Gandalf Data Ltd.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Distribution: na
Date: Mon, 27 Jul 1992 15:32:53 GMT
Lines: 62

In <[e-mail]> [e-mail] (Art Berggreen) writes:

>In article <[e-mail]> [e-mail] (Dave Carr) writes:
>>We make a COMPRESSION BRIDGE.  We don't max out at 4:1.  That's the
>>typical performance however.  Dual 64K links, and soon 256K or 384K.
>>Currently requires our bridge at remote, but PPP interoperability
>>in the works.

>I just want to point out to folks not familiar with compression technology
>that "typical" compression ratios are highly dependent on the data stream.

No kidding.  I wasn't trying to snow anyone.  I was merely trying to point
out that even at 12:1, we have the horsepower to keep the link full.

In fact, some algorithms such as LZW are not linear.  As the compression
ratio increases, the CPU time per byte compressed decreases.  The same
is true for most LZ77 variants.  Arithmetic encoding is fairly linear.

Typical is what you get when you run in many customer sites.  Not everyone
spends all day sending binary data.

>When we added compression to our bridge/router we tested several compression
>algorithms and many different types of data.

You make it sound that we did not.  Our product has been in the field for
over a year.

>Data that is already
>compressed often expands unless the algorithm can quickly switch into
>a "transparent" mode and back.

Or unless the algorithms expansion is so low that it doesn't make a
difference.  The 50% expansion of LZW is clearly not acceptable.
However, there are LZW variants that expand at most by 6% and V.42 bis.
We use neither however, and our worst case expansion is 1% (on 64
byte packets), and .05% on 1500 bytes.

>Binary computer data often only gets
>about 2:1 compression.  Ascii text can range from 2:1 to 4:1 or better
>depending on the nature of the text.  Contrived sample data that can
>really exploit the compression algorithm can give 25:1, 50:1, or better
>(depending on several factors).  I don't want to say that 4:1 compression
>won't be typical for some networks,  just don't expect it until you try
>it on your net or have some idea about the compressibility of your network
>data.

Exactly.  The marketting types really have a hard time putting the compression
specs on paper.  You need a "Calgary Corpus" set of benchmarks, or everyone
will be quoting there own favourite numbers.  Note, the Calgary Corpus is a
set of benchmarking files for measuring archivers such as ZIP.

>Also, interoperability requires compatible algorithms at both ends.
>Due to the rapid evolution of compression technology and the state of
>standarization, it might be a while before you can expect general
>interoperability.

PPP with compression should be available shortly after INTEROP.  We just
need to standardize on the compression algorithm.
--
Dave Carr               | [e-mail]       | It's what you learn,
Principal Designer      | TEL [phone]     | after you know it all,
Gandalf Data Limited    | FAX [phone]     | that counts.