Path: utzoo!utgpu!jarvis.csri.toronto.edu!torsqnt!tmsoft!mason
From: mason@tmsoft.uucp (Dave Mason)
Newsgroups: comp.dcom.modems
Subject: re: MNP 5 vs. uucp 'g' (vs. Telebits)
Message-ID: <1989Sep7.235838.11756@tmsoft.uucp>
Date: 7 Sep 89 23:58:38 GMT
References: <124236@sun.Eng.Sun.COM>
Reply-To: mason@tmsoft.UUCP (Dave Mason)
Followup-To: comp.dcom.modems
Organization: TM Software Associates, Toronto
Lines: 67

In article <124236@sun.Eng.Sun.COM> shannon%datsun@Sun.COM (Bill Shannon) writes:
>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.

I've just started using a Microcom AX/96xxc.  Sending compressed news
batches we're getting about 600 cps.  Using 9600 or 19200 is
irrelevant.

>  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.

The only thing that I've found that may help a little is setting the
block size to 64 characters instead of the default 256 (the AT \A0
command).  It doesn't make a huge difference, but it does (from my
preliminary tests) help about 20% (I'm going to run 'week-on and
week-off' tests to be sure).  I tried 128 and 192 to no real advantage
(over 256).  What we really need is to be able to tell it 'if you
don't see any characters for 1ms, ship off what you've got'.

>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?

This (600 cps) seems sort-of right:
   1) the data compression of course won't help, and may hurt.  I
haven't tried turning it off yet to see what happens.  These marvelous
quoted speeds of >960cps of course assume that the data can be compressed.
   2) on a telebit I usually see 1000-1100 cps which is on the order of
2/3 of the 'raw data rate' of 14400bps (max).
   3) given that the MNP-5 is really only running at 9600, 600cps is on
the order of 2/3 of the 'raw data rate'

On the telebit, turning compression off appeared to gain me about 5%
(again, shipping compressed -b 16 news batches).  So after I've been
using this long enough to get some useful stats, I'll try that.

>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.

some of {f,t,e} protocols do error checking, but only on a
'whole-file' basis & reship the whole file if something went wrong.
This is probably unlikely enough between the computer and the modem
that file level checking is probably sufficient (if your silo
overflows are frequent, I'd claim you had more problems than modem
throughput).  I don't know if anyone has tried running a telebit using
these protocols instead of 'g'.  It would be interesting to hear the
results.

The bottom line?  From here, today, it's "get a Telebit" for 60-70%
better throughput.  But I'm using this Microcom because the person at
the other end of the phone line found the Telebits to be a crock, so I
guess it just goes to show you...

	../Dave