> Once upon a time Al Hopper shaped the electrons to say...
> >OK I just don't get it! Lets say you get an average of 2:1 compression
>
> You won't in the real world.
>
> >using compression on a TCP/IP connection. Why would you _not_ want 2:1
> >compression on a T-1 link? Whats the alternative - get another T1
>
> Compression introduces latency. The more data you try to compress, the
> worse it will get.
>
Point taken.
> You will also eventually overwhelm the CPU. It is widely accepted that
> trying to compress a full T1 is a *bad* idea.
>
Yes, but you don't use the _one_ CPU to do everything. STAC is available
as a custom IC. You could handle compression of 2 or 3 T1s using an off-
the-shelf 8-bit microprocessor. And 8-bit micros are very inexpensive.
If you don't like an 8-bit micro then use an AMD 386/486 16-bit micro.
Same point - CPU hardware is cheap.
Essentially the PM boxes are embedded systems. If you go to a
multi-processor architecture in an embedded product the software becomes
dramatically simpler. Different functional blocks become independent,
since they run with their own dedicated resources. The increased cost of
the hardware is quickly dwarfted by the reduced complexity of the
software. Software development (NRE) and life cycle costs are vastly
reduced and more than offset the cost of the additional hardware. I think
that if you really sit down with the hardware/software designers you _can_
make a viable business case for this!
Latency: If you reduce the block size or packet size that you use to do
the compression then latency problems are minimized - at the expense of
the compression ratio you achieve. So if the channel, or byte stream,
you are compressing is busy you compress larger blocks of data and if the
data channel is moving fewer bytes you compress smaller blocks (and suffer
lower compression ratios) to improve latency.
Either way the Livingston customer is the winner. Like I said bandwidth
costs $$. So I am saying that in a busy situation with all ISDN data
streams you compress large blocks and get 2:1, while in a low volume
situation, where you have mainly modem users you get 1.2 or 1.3:1 and
still keep the latency issue under control. But if you don't have many
modems users, you could dynamically bypass the compression engine - so now
you can still remote 36 B-channels with 10 B-channels (rounding out the
numbers).
> >carrying traffic you can bill for. Now I know this is not a full T1 link,
> >but you see the economic benefits of compression?
>
> It doesn't work the same way on a line that is highly utilized. There are
> know statistics on dialin usage, etc. You design for those. Trying to
> deal with a full T1 that is stuffed full of data is different from dealing
> with 23 B channels all being used by dialin users.
>
> >a given pipe (compression) is a good economic deal. And this is
> >independent of the size of the pipe - right?
>
> It would raise the HW costs significantly to give it the kind of horsepower
> needed. And it would introduce latency - which is the bane of any
> interactive application. Latency is the number one problem for gaming for
> instance.
>
Point taken.
> -MZ
>
.... out of context .....
> MZ says: "It is widely accepted that trying to compress a full T1 is a
> *bad* idea."
This "widely accepted" translates to this: "It has yet to be engineered
correctly". Let me make a prediction: Livingston will migrate to a
multi-processor architecture over time.
I'm not trying to be argumentative here, but I've worked on software
systems and embedded systems for a long time. I fight this status quo
battle every day - one successful implementation at a time.
Al Hopper Logical Approach Inc, Plano, TX. al@logical-approach.com
(972)-379-2133 or (972)-849-5765. Fax 972-379-2134