Newsgroups: comp.dcom.modems
Path: utzoo!utgpu!watserv1!watmath!att!att!cbnews!mjs
From: mjs@cbnews.att.com (martin.j.shannon)
Subject: Re: USRobotics Courier HST/ix?
Organization: AT&T Bell Laboratories
Date: Fri, 19 Oct 90 17:08:18 GMT
Message-ID: <1990Oct19.170818.13847@cbnews.att.com>
Summary: depends....
References: <540.2718D7BC@zswamp.fidonet.org> <1990Oct15.120645.7065@nstar.uucp> <1990Oct18.181733.18413@nstar.uucp>
Lines: 38

In article <1990Oct18.181733.18413@nstar.uucp>, larry@nstar.uucp (Larry Snyder) writes:
> I am considering replacing the HST (14.4) modems with V.32
> with v.42bis and MNP5 here on nstar - with the idea that 
> UUCP throughput with the V.32 and v.42bis will be very close
> to that of the PEP modems.  Do you agree (that V.32 and PEP will
> produce about the same throughput on uucp transfers)?

Larry, for UUCP ('g' protocol), the Telebits have quite an advantage --
if both ends are Telebits -- in that the modems themselves "spoof" the
uucp 'g' protocol.  Between the modems, I suspect something like the
'e' protocol is used: just blast the bits, and let the normal error
recovery do its thing.  Well, it's a little more complicated than that,
but probably not much.  Be all that as it may, my guess (educated, but
a guess nonetheless) is that you'll get worse than PEP if you use 'g'
protocol, and at least comparable to PEP with 'e' protocol.  Depending
on the traffic contents, you may be able to do better than PEP using
'e' protocol.  Let me (and the net!) know how that works; my HST DS
hasn't been upgraded to V.42bis yet....  Also, if you get modems with
V.32bis (not yet a standard, right, Toby?) and V.42bis, you should
certainly be able to beat PEP with 'e' protocol (again, assuming an
equivalently equipped neighbor, and an error-free uucico->uucico path).

Did you say that you do or don't have 'e' protocol available to you?
For non-Telebit-high-speed-modems, my recommendation is to use 'e' if
you (and your neighbor) support it.  Actually, even for 2400 baud, it
might make enough of a difference (again, with the restriction that
both sites *must* have hardware flow control (i.e., error free path
from uucico to uucico)).

I use the FAS driver and a 16550AFN uart (THANKS, Uwe!), and typically
get 97% of the 14400 b/s available (according to uutraf, and after
weeding out "very short" transfers -- less than 1k: they tend to report
transfer rates greater than 38.4Kb/s (I lock interface speed to
38.4Kb/s)!).
-- 
Marty Shannon; AT&T Bell Labs; Liberty Corner, NJ, USA
(Affiliation is given for identification only:
I don't speak for them; they don't speak for me.)