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

Internet Message Format | 1992-07-23 | 1.9 KB

Xref: sparky comp.dcom.servers:54 comp.dcom.lans.ethernet:1453
Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!uwm.edu!ogicse!network.ucsd.edu!ucsbcsl!spectrum.CMC.COM!fennel.acc.com!art
From: [e-mail] (Art Berggreen)
Newsgroups: comp.dcom.servers,comp.dcom.lans.ethernet
Subject: Re: Microcom B-Routers (TCP/IP)
Message-ID: <[e-mail]>
Date: 23 Jul 92 17:29:32 GMT
Article-I.D.: acc.1992Jul23.172932.5072
References: <[e-mail]> <[e-mail]>
Organization: ACC, Advanced Computer Communications
Lines: 26

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.
When we added compression to our bridge/router we tested several compression
algorithms and many different types of data.  Data that is already
compressed often expands unless the algorithm can quickly switch into
a "transparent" mode and back.  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.

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.

Art