NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/compress/3217

Internet Message Format | 1992-09-08 | 3.7 KB

Xref: sparky comp.compression:3217 comp.dcom.modems:13116 comp.protocols.misc:675 comp.protocols.tcp-ip:4343
Newsgroups: comp.compression,comp.dcom.modems,comp.protocols.misc,comp.protocols.tcp-ip
Path: sparky!uunet!usc!cs.utexas.edu!torn!cunews!hobbit.gandalf.ca!dcarr
From: [e-mail] (Dave Carr)
Subject: Re: Any experiences with Compressing TDMs?
Message-ID: <[e-mail]>
Keywords: compress TDM multiplexor leased-line satelite
Organization: Gandalf Data Ltd.
References: <[e-mail]>
Date: Tue, 8 Sep 1992 15:18:26 GMT
Lines: 71

In <[e-mail]> [e-mail] (Paul Nash) writes:

>We are considering installing a pair of Symplex Datamizer compressing
>TDMs, to optimise the use of an international leased line.  However, we
>would like to find out others' experiences first.  For those who don't
>know, the device is basically a TDM with a data compressor attatched to
>the aggregate channel.

First, the units are STATISTIC multiplexers, not Time Division Multiplexers.
Big difference.  A traditional TDM will just interleave the data from
multiple channels, usually at the bit level, into one data stream.
TDMs are transparent to the data.

A statmux typically allocates the composite link bandwidth on demand.
Thus, one channel can use up to all the bandwidth available on the link
if no other channels have nothing to send.

>We would like to know of any good or bad experiences in the following
>areas:

>1) Reliability:

Better than a traditional TDM.  Statmuxes run error corrected links.
As far as hardware goes, the Symplex box (at least the last one I looked
at) used dual Z80's, DRAM, EPROM, etc.  Should have a low MTBF.
The've been making the product for some 10 or more years.  I would
hope it's reliable by now :-)

>2) Throughput:  the local marketing people claim 4:1.  From experiences
>                with modems, I would guess that 2:1 is a better bet in
>        the real world, but would like to hear what sorts of
>        throughput people actually get.

Well, there are several factors here.  First, Symplex does spoofing.
They emulate the protocol to remove unnecessary overhead from polls and
protocol headers and trailers.  This is protocol dependent and will
vary between applications.

Second,  async data overhead (stop, start bits) are removed.

Third, the symplex unit uses several algorithms in parallel, and choses
the best, not just MNP5 or V.42 bis.  I believe it is superior in this
respect.

But be realistic.  It depends on the data.  I would be comfortable
with a claim of 3:1 for these units over a spead of applications.

>3) Satelites:  we want to use these over a satelite link.  Does the
>               increased latency have any nasty side-effects?

The statmux/compression delay is insignificant compared to the .25 second
delay from the satellite hop.  In fact, it should improve the line
delay.  Two reasons for this.  First the compressed packet is shorter
and will get tghere sooner.  It is also less likely to be corrupted.
Satellite hops don't have the best error rate :-)  The statmux will
restansmit sooner than the application can.

>The types of traffic that we plan to shove down the line include X.25,
>SL/IP or PPP and SNA (perhaps).

>If there are any other comments, or other products, I would appreciate

I would recommend our compressing stat mux only if cost or number
of channels are issues.

I don't think we compare to Symplex w.r.t. compression.  Their's is a
fine unit.  I believe we did or still do OEM it.
--
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.