NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/dcom/modems/11266

Internet Message Format | 1992-07-27 | 4.7 KB

Xref: sparky comp.dcom.modems:11266 can.uucp:180
Path: sparky!uunet!wupost!cs.utexas.edu!torn!cunews!revcan!ecicrl!eci386!woods
From: [e-mail] (Greg A. Woods)
Newsgroups: comp.dcom.modems,can.uucp
Subject: Re: UUCP 'g' vs. MNP & V.42
Message-ID: <[e-mail]>
Date: 27 Jul 92 19:09:40 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Elegant Communications Inc.
Lines: 86

In article <[e-mail]> [e-mail] (John R MacMillan) writes:
> [Greg A. Woods wrote:]
> |Anybody running MNP at any level with UUCP 'g' should have their modem
> |and UUCP configurations examined!  :-)
>
> I don't know, I use MNP-5 (and hence 4) on two of my mostly-mail (ie.
> uncompressed) connections and I see much improved throughput.  Even on
> much of the compressed stuff there is some improvement, though there
> is sometimes also degradation.

As I said, it depends upon the compressibility of the data, the
configuration of the UUCP 'g' parameters, the exact nature of any line
errors, and the ability of the modem to spoof UUCP 'g'.

> |MNP-4 is link-layer protocol that retries erroneous packets.  UUCP 'g'
> |is a link-layer protocol that retries erroneous packets.  Guess what
> |-- the don't get along very well!
>
> Why not?  The 'g' protocol would just never (or very rarely; only in
> modem-to-computer failures) see failures.  In my case, where the 'g'
> protocol isn't spoofed at the modem, and has to go all the way to the
> computer, that's a win.

Ah, but, as Sean Doran noted in private e-mail to me, "MNP-4 is a
half-duplex protocol."  The timing issues involved can cause
significant degradation to UUCP 'g' throughput due to uucico timeouts
when waiting for ACK's with small window sizes.  Because of this it is
often far more efficient to allow UUCP 'g' to do its own error
correction.  Mind you, on a somewhat noisy line, MNP-4 may be be able
to keep uucico from timing out where it normally would, and thus show
increased throughput *given_the_same_line_conditions*.  This
possibility is dependent upon the current window size the uucico's are
using, and on the characteristics of the errors.

Again, with modem-to-host spoofing, MNP-4 is a definite win because of
the synchronous transmission and guarantee of eliminating uucico
timeouts; and without, you're better off dropping the MNP, as the
timing clash may result in as much as a 20% reduction in throughput.

[The latter is a measured average, not theoretical, from regular MNP-4
connections over V.22bis (i.e. 2400bps).]

So, in general, unless you have specific requirements, it is best to
disable MNP completely when dialing out with UUCP.

> |...  [V.42bis, MNP-5, and LZ are all variants of the Lempel-Ziv
> |compression algorithm, though most implementations of MNP-5 *reduce*
> |throughput with pre-compressed data, and each have varying degrees of
> |efficiency and ratios of compression.]
>
> It's my understanding that all MNP-5 implementations will sometimes
> reduce throughput of some pre-compressed data because the compression
> is always done; it's not dependent on the implementation, but on the
> data.

Well, sort of.  The MNP-5 variation of Lempel-Ziv will often result in
inverse ratios of compression.  I've seen throughput for files
(compressed news) drop to below 5% of normal throughput when
transmitted using MNP-5 and V.32 on some modems.

However, when one of my downstream news sites tried picking up
compressed news batches with MNP-5, and gave up quickly -- we saw UUCP
throughput drop to ~40 cps (i.e. ~18% of normal (Telebit T-1000 to
some clone) (i.e. the T-1000 implementation of MNP-5 is either a bit
smarter than the Hayes one, or the timing clash with this particular
site was far less of a problem (maybe due to V.22bis vs. V.32, or due
to better quality lines, or due to a larger window size being
possible).

> This is unlike V.42bis, where if the compressed block is larger
> than the original, the uncompressed block is sent.

Exactly, which is why V.42bis is safe with compressed data.  Not to
mention that is offers 4:1 compression when possible (vs. 2:1 with
MNP-5).

However, as Bruce Becker says, allowing compression on a Telebit
WorldBlazer or T-3000 may not be worthwhile if you transfer mostly
compressed data, because MNP cannot be completely disabled, and as a
result may end up being negotiated; and because the T-2500 cannot
spoof when doing V.42bis.
--
                        Greg A. Woods
[e-mail], [e-mail]  VE3TCP    ECI & UniForum Canada
[phone] [h]  [phone] [w]    Toronto, Ontario; CANADA
Political speech and writing are largely the defense of the indefensible-ORWELL