Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!newstop!sun!datsun!shannon
From: shannon%datsun@Sun.COM (Bill Shannon)
Newsgroups: comp.dcom.modems
Subject: MNP 5 vs. uucp 'g'
Message-ID: <124236@sun.Eng.Sun.COM>
Date: 6 Sep 89 20:57:04 GMT
Sender: news@sun.Eng.Sun.COM
Lines: 33

I've been evaluating V.32 modems and have run into a problem with MNP 5
operation.  Talking to the modem at 19200, with the modem doing MNP 5
(error correction and compression), and using uucp with the 'g' protocol,
I expected to get 1200 - 1500 characters per second throughput.  However,
what I'm actually getting is something like 450 cps.  It turns out that
the problem is related to a clash between the uucp 'g' protocol and the
MNP protocol.  uucp is sending 64 bytes packets and expecting a response.
MNP 5 sends 128 byte packets.  If less than 128 bytes come in to the
modem, it waits a bit and then decides no more is coming and sends a
partial packet.  Unfortunately, this wait is on the order of 20 milliseconds
and is killing uucp 'g' protocol performance.

Have any of you people using MNP 5 (or higher) run into the same problem?
In particular, I've seen some claims of fantastic throughput using the
Microcom modem at 38400 baud with MNP 9.  Are people using uucp's 'g'
protocol in this configuration?  Does MNP 9 not have this problem?

You might think that, since the modem is providing error correction, you
could use one of the uucp error-free protocols ('t' or 'e').  In fact,
using one of those protocols does give the expected throughput.  However,
the modems only guarantee that the data makes it from one modem to the
other without errors; there is no guarantee that the data will make it into
the host without errors.  While I'm not really worried about "line noise"
corrupting the data between the modem and the host, I am worried that the
host can drop data coming from the modem, for instance the familiar "silo
overflow" problem if the host gets too busy.  As far as I can tell, the
uucp error-free protocols won't detect this condition, thus possibly
resulting in corrupted files being transferred.  Has anyone else considered
this problem and perhaps dealt with it?

Thanks for any help.

	Bill Shannon