NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/dcom/modems/18601

Text File | 1992-12-29 | 3.2 KB | 79 lines

Newsgroups: comp.dcom.modems
From: [e-mail] (Lawrence Kirby)
Path: sparky!uunet!pipex!demon!genesis.demon.co.uk!fred
Subject: Differences between modems...
Distribution: world
References: <[e-mail]>
Organization: BT
Lines: 66
Date: Tue, 29 Dec 1992 00:02:51 +0000
Message-ID: <[e-mail]>
Sender: [e-mail]


In article <[e-mail]> [e-mail] writes:

>
>On Mon 14 Dec at 15:59 Lawrence Kirby wrote in article
><[e-mail]>:
>
> LK> In article <[e-mail]>
> LK> [e-mail] writes:
>
>[re V.42bis]
>
> LK> Does it specify when the transmitter should/should not send
>
> LK> data compressed?
>
>This matter came up in an Australasian Fidonet sysop conference,
>and I'm adapting what I wrote there:
>
>CCITT Recommendation V.42bis does suggest how to calculate
>compression efficiency (section II.3, quoted in my previous
>message), but does state "The data compresssion function shall
>periodically apply a test to determine the compressibility of the
>data. The nature of the test is not specified in this
>Recommendation; however it would considst of a comparison of the
>number of bits required to represent a segment of the data stream
>before and after compression."
>
>The Recommendation goes on to state "If the data compression
>function is in the transparent mode and determines that data
>compression would be effective it shall ... enter compressed
>mode" and  "If the data compression function is in the compressed
>mode and determines that the data stream is currently not
>compressible, it shall ... change the state to transparent mode"
>(section 7.8).
>
>On a related area of V.42bis performance, the method of
>determining whether the BTLZ dictionary needs to be reset is not
>defined in CCITT Recommendation V.42bis either, but would
>probably be useful when more than half the entries are stale i.e.
>haven't been encountered recently in the data stream.
>
>None of this suggests that it should be particularly difficult to
>achieve no loss of throughput with non-compressible data while
>V.42bis data compression is enabled. I'd be interested in hearing
>why some modems haven't achieved this.
>

Well here's my guess! If a modem is going to pass data through as fast as
possible it will have to start transmitting a block before it can determine
whether that block is compressible or not. Therefore it must guess whether the
block is compressible from previous data it has transmitted. This is fine
unless the data varies rapidly between compressible and incompressible (e.g.
a multiplexed line such as SLIP). It's quite easy to envisage a senario like
this where the modem ends up compressing incompressible blocks and not
compressing compressible blocks.

Of course there's also the processing overhead of the compression which may
be too much for some modems. Modems need to go through the compression process
even when they aren't sending data compressed since they still need to
determine whether the data is compressible or not.

-----------------------------------------
Lawrence Kirby | [e-mail]
Wilts, England | [e-mail]
-----------------------------------------