🚀 go-pugleaf

In article <1jvjuvINN8l6@ftp.UU.NET> PTomblin@gvc.com writes:
[Is modem compression a good idea when transferring news?]
>I'm most interested in hard data on PEP, TurboPEP and V32bis/V42bis.

Well, I don't have any hard data to give you, but I can tell you a bit
about modem compression.

First of all, there are two types of compression commonly used over
dialup modem links: MNP5 and V.42bis.  Of these two, V.42bis is the
one to use if you have a choice, since MNP5 has the rather undesirable
quality of expanding precompressed data, and thus *reducing*
throughput.  V.42bis will notice when the compressed version of the
data is bigger than the uncompressed version, and send that packet
uncompressed.

So, in a sense, your friend is right -- using MNP5 compression on a
link *will* slow down throughput when you're sending compressed news
batches.  Using V.42bis compression, on the other hand, shouldn't slow
anything down -- unless you or your friend have a cheap underpowered
modem that can't run the data pump at full speed and do data
compression at the same time.

The compression algorithm used by PEP, while not similar to MNP5,
shares with it the quality of not checking the compressed data's size
before sending it.  So, PEP compression should be turned off when
transferring compressed data as well.  TurboPEP compression is just
V.42bis, so that's okay; I'm not sure, however, whether it's possible
to only turn on compression for a TurboPEP connection.

So, if you can use a compression mode that won't expand your
precompressed data, you might want to try using it.  Otherwise, don't
worry about it unless you have a large amount of uncompressed traffic
(i.e., mail) flowing over the link; if you do, you might want to look
into using compressed BSMTP instead of regular rmail.

It's been my experience, though, that most of the throughput problems
encountered by UUCP users stem from the awful parameters used by most
UUCP implementations, not from compression problems.  64-byte packets
are fine if you're sending data at 1200bps or even 2400bps, but at
V.32bis and PEP speeds it really creates a problem.  The latency of
fast modem links is such that the ACKs can't get back to the sending
computer before it runs out of data in the window, and thus the it
winds up sitting around for the ACK to travel over the wire back to
your computer.  In addition, using small packets means that UUCP has
to do numerous small individual writes, generating a lot of overhead
and context switches.

What you want to do is get a version of UUCP on both ends that can use
big -- 512-byte or 1024-byte -- packets.  By using larger packets, you
eliminate the latency problems, and also increase efficiency by
allowing uucico to make fewer write(2) system calls.

Unfortunately, most stock versions of UUCP don't support big packets.
To my knowledge, the only stock version that *does* is the HDB UUCP
distributed with SVR4.  If you don't have SVR4, you'll have to get
Taylor UUCP and build it for your OS.  Of course, there are lots of
other reasons to get Taylor UUCP; I replaced the SVR4 UUCP on my
system even though it *could* handle big packets.

Okay, I lied: Here are some hard numbers.  Using 1024-byte packets and
7 windows, I'm getting in the neighborhood of 1700cps over a V.32bis
modem link with V.42 and V.42bis.  My computer is a 486/33 running
SVR4 and Taylor UUCP v1.04gamma; his computer is a NeXTstation running
NeXTOS 3.0 and an unknown version of Taylor UUCP.  Neither machine is
noted for being a real computing powerhouse, but my machine manages to
keep the data pipe full most of the time (i.e., the modem has to
throttle my machine by dropping CTS before the entire window is sent).
Another site, a DECstation 5000 running Ultrix 4.3, using 64-byte
packets, 7 windows, and V.32 (n.b., not V.32bis) with MNP5, is lucky
to get 800cps.  Yet another site, a 386SX/25 running SCO Unix 3.2v4.1,
using 64-byte packets, 7 windows, and V.32bis with V.42bis, gets
850-875cps.

-- 
Marc Unangst, N8VRH         | "Of course, in order to understand this you
mju@mudos.ann-arbor.mi.us   |  have to remember that the nucleus of the atom
                            |  is squishy."
                            |    -W. Scheider, from a Physics lecture