Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!elroy.jpl.nasa.gov!usc!apple!vsi1!teda!netcom!gandrews
From: gandrews@netcom.COM (Greg Andrews)
Newsgroups: comp.unix.sysv386
Subject: Re: SYSV R4.0 High speed UUCP
Summary: No biggie - Bernd just overstated the case.
Keywords: UUCP V.32 V.42bis PEP
Message-ID: <24318@netcom.COM>
Date: 16 Feb 91 18:10:26 GMT
References: <1991Feb7.224752.1932@rwwa.COM> <1991Feb10.201122.29918@comp.vuw.ac.nz> <1991Feb15.054602.913@jadpc.cts.com>
Followup-To: comp.unix.sysv386
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
Lines: 66

In article <1991Feb15.054602.913@jadpc.cts.com> jdeitch@jadpc.cts.com 
(Jim Deitch) writes:
>
>> [quoting Bernd Gill]
>>With high speed modems it is most important to have flow control set up
>>properly. Any lost or corrupted packets cause alarms. Depending
>>on what protocol you are using you need the following flow control:
>>
>>Protocol Used           Modem       	   		Computer
>>--------------------------------------------------------------------
>>g-protocol		xon/xoff OFF			xon/xoff OFF
>>			RTS/CTS  ON			RTS/CTS  ON
>>			Error Correction OFF
>>
>>Modem Error Correction sometime interferes with the g-protocol (which
>>uses software error correction) and should be OFF.
>
>HUH?
>
>    That means:
>1.  I can't use a Telebit modem's uucp spoofing because the modem
>    has to do pep for it to work, but that pep is an error correcting
>    protocol done by the modem.  Right?
>
>2.  That the uucp transfers that have been happening the last six
>    months wern't really happening, and all those bits are on the
>    floor behind my computer?
>
>3.  You made a mistake in the chart, and I am responding before the
>    corrected one comes out.
>
>Which choice?
>

Um...er...door #3, but not because he's 'wrong' -- he's just overstating
the case a little.

Among all the modems on the market, there are very few that can separate
the computer--->modem flow control path from the modem--->computer flow
control path.  For those modems, you have no choice but to use RTS/CTS 
(if your computer can support it), or disable all flow control.  Telebit
modems have the ability to define different types of flow control in the
two directions.  This allows the modem to ignore XON and XOFF bytes from
the computer (they might appear in uucp transfers) while still sending
XON/XOFF to the computer.  The modem becomes transparent to data flow
while still retaining the ability to pause the computer.

Since the Telebit PEP mode has special support for uucp, it's able to do
important things like disabling the XON/XOFF flow control to prevent
alarms from the unexpected flow control characters.  Definitely the
exception to the rule (and note that this only happens when the modem
is doing uucp spoofing -- plain connections would still have XON/XOFF
active).

Also, the assertion that modem error correction "interferes" with uucp
is probably not right.  There have been a lot of reports that error
correction caused trouble with uucp, but just as many reports that it
seems to work fine (my own experience).  Most modems enable flow control
and allow higher RS232 speeds when error correction is used.  Could be
the problems were caused by the modem's buffering and/or flow control 
rather than the error correction itself.

-- 
.-------------------------------------------.
| Greg Andrews      |   gandrews@netcom.COM |
`-------------------------------------------'