From: dawson@hobbes.bsan.bls.com (Willard Dawson)
Newsgroups: comp.bbs.waffle
Subject: Re: UUCICO SPEED
Date: Tue, 15 Dec 1992 22:27:39 GMT
Organization: BellSouth Systems Integration

dogbowl@dogbox.acme.gen.nz (Kennelmeister) writes:

>dawson@willard.UUCP writes:
>
>> Perhaps you're not aware that some modems allow one to enable v.42bis, but
>> to further disable simple MNP5 compression?  That is how I've got mine set.
>> If your modem asks for v.42bis, I give it.  If you ask from MNP5, you don't
>> get it.  For outbound calls, I have the same configuration.  I only ask for
>> v.42bis, and exclude simple MNP5.  On my T'bit modem, I exclude all data
>> compression, especially PEP-compression.
>
>Why on Earth would you want to disable the fallback standard?
>Surely when it comes to compression, you either want the best you can
>do, or have none at all.

(First, the "fallback" standard I've disabled has only to do with compress-
 ion.  Calls may certainly fallback to other levels of error-correction.
 If an incoming call asks for anything in MNP1-4, they get it.  If they
 ask for v.42, v.42bis, or PEP, they get it.  If they ask for MNP5, they
 get MNP4.  If they ask for PEP-compression, they only get PEP.)

(When it comes to compression...)
No.  You see, MNP5 compression (which uses a form of Huffman encoding,
I believe) is not too good.  In fact, if you use MNP5 with LZH compressed
files, the resulting data will typically be larger in size than the
original file.  A similar result sometimes occurs when using v.42bis
compression with pre-compressed files.  The advantage of v.42bis over MNP5
is that v.42bis is adaptive -- it will disable itself if it determines
that the effects of the compression is file-expansion.  The time required
for v.42bis to recognize file-expansion depends on the "frame-size" (I'm
forgetting the actual term, .. but it's a modem config parameter).  So,
if you're using v.42bis, you may be losing the throughput battle during
the time that the protocol is expanding the data, and while the modem is
doing it's calculations of compression efficiency.

>> The topic is not standards documents, but rather modem documentation.
>
>True, but as CCITT V42bis documentation explicitly makes mention of the
>standard's fallback ability to MNP5, and incorporate major elements of
>MNP5, it also comes down to peoples understanding of the relevent
>standards.
>
>Most CCITT documents are available at your local library via interloan
>systems, so you don't have to pay exorbitant amounts of cash to read
>them. They give a solid grounding in the principles, though they do tend
>to be a bit 'dry'.
>
>Perhaps this discussion should be continued in comp.dcom.modems or
>alternatively comp.mail.uucp if we want to discuss the pros and cons
>of compression when using UUCP 'g'
>(Anyone remember the "UUCP 'g' must die!" thread in comp.dcom.modems
> earlier this year?)

The discussion of the effects of modem-compression on pre-compressed
data has occurred on several occasions in the past in comp.dcom.modems.
That IS the proper place for this discussion, likely.

>--
>Alan Brown. (SysAdmin)                          c/- 238a Tremaine Ave
>dogbowl@dogbox.acme.gen.nz                      Palmerston North
>Dawghaus BBS -> +64 (6) 357-9245                New Zealand
--
 Willard Dawson, BellSouth Advanced Networks, 1100 Johnson Ferry Road, Ste. 880
 Atlanta, GA  30342, Voice: +1 404 303 2343, UUCP: gatech!vdbsan!hobbes!dawson
 Internet -> X.400:  /G=W/S=DAWSON/O=BSAN/ADMD=BELLSOUTH/C=US/@sprint.com
 Percent hack:  dawson%vdbsan@gatech.edu   ::    Standard disclaimer applies.