Newsgroups: comp.dcom.modems
Path: utzoo!utgpu!cunews!hobbit.gandalf.ca!dcarr
From: dcarr@hobbit.gandalf.ca (Dave Carr)
Subject: Re: Uses of V.42 (bis?) data compression
Message-ID: <1991Apr15.133440.19656@hobbit.gandalf.ca>
Organization: Gandalf Data Ltd.
References: <10334@pitt.UUCP> <3908.280363d4@hayes.uucp> <1991Apr12.132116.11546@hobbit.gandalf.ca> <529@aria.ascend.com>
Distribution: na
Date: Mon, 15 Apr 1991 13:34:40 GMT
Lines: 21

In <529@aria.ascend.com> marc@aria.ascend.com (Marco S Hyman) writes:

>Dave, how would you feel if you kept putting bytes into one end of a data link
>and nothing came out the other end?  Why?  Because the first end can still do
>some more compression on the data and doesn't have a new symbol to send.
>Compression efficiency is only half the problem -- you want to keep your
>bandwidth filled.  What's the use of compressing more while the bandwidth sits
>idle.  When the (very) efficient compression symbol is finally sent there is
>even more delay added to output the cleartext at DTE interface speeds. All
>The only result of making compression independant of the carrier speed is
>increased response time.

>Throughput is not the only factor in communcations links -- you can never
>forget about response time.

I agree.  Assume the Forwarding Algorithm is send packet when the link is idle.  
Use the SAME algorithm in a NON-COMPRESSION link as well.

Both compressed and uncompressed links will attain a steady state throughput.
I think you will find that the compression ratio is still independent of
the link speed.