Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!spooky!witr
From: witr@rwwa.COM (Robert W. Withrow)
Newsgroups: comp.unix.sysv386
Subject: Re: Equinox question
Message-ID: <1991Feb15.164415.19733@rwwa.COM>
Date: 15 Feb 91 16:44:15 GMT
References: <27B79130.5C72@telly.on.ca> <1991Feb14.224748.18446@pcserver2.naitc.com> <1991Feb15.083043.11636@pegasus.com>
Organization: R.W. Withrow Associates
Lines: 33

In article <1991Feb15.083043.11636@pegasus.com>
  richard@pegasus.com (Richard Foulk) writes:

>Uucp connections in general are not "self-pacing", ...
>Pegging your port speed at 19200 and trying to make uucp exchanges with
>other modems at 1200, 2400 and 9600 V.32 will most likely fail...

My experience indicates that these statements are incorrect.  The UUCP
`g' protocol *is* ``self-pacing'' in the sense that it has a limited
window and limited packet sizes, and is an ARQ protocol, requiring an
acknowlegement for each packet transmitted.  Thus the flow-rate is
ultimately controlled by the receiving computer.

In the case of Telebit modems, for PEP and Direct V.32 (but not V.42
LAP-M) connection, the modem ``spoofs'' the `g' protocol, and thus the
pacing (aka flow-control) is performed by the modem in this way.

With other modems (and telebit modems using LAP-M), the pacing is done
by the two computers via the `g' protocol.  In cases where the
DTE-to-modem bit rate is higher than the modem-to-modem bit rate,
modern modems generally have enough buffer capacity to run UUCP `g'
protocol without using *any* DTE-to-modem flow control!

As an example, UUNET has *all* DTE-to-modem flow control disabled on
their modems.  On my system I have found that I get the most reliable
operation by doing likewise.  I have my DTE speed set at 38400 BPS,
and have successfully performed UUCP `g' to other modems operating at
2400, 4800, and 9600 BPS.

-- 
---
 Robert Withrow, R.W. Withrow Associates, Swampscott MA 01907 USA
 Tel: +1 617 598 4480, Fax: +1 617 598 4430, Uucp: witr@rwwa.COM