Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!mips!apple!netcomsv!gandrews
From: gandrews@netcom.COM (Greg Andrews)
Newsgroups: comp.mail.uucp
Subject: Re: Telebit Registers (was Re: UUNET Problems)
Summary: Disabling all flow control may not be a good idea.
Message-ID: <1991Jun14.040846.4738@netcom.COM>
Date: 14 Jun 91 04:08:46 GMT
References: <1CE00001.hv3cvx@tbomb.ice.com> <1034@trac2000.ueci.com>
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
Lines: 69

In article <1034@trac2000.ueci.com> das@trac2000.ueci.com (David Snyder) writes:
>In article <1CE00001.hv3cvx@tbomb.ice.com>, time@ice.com (Tim Endres) writes:
>->
>-> This is definitely wrong. I would be very suspicious of my register
>-> settings. Here are mine (S58 and S111 are important):
>->
>->  [unimportant parts of Tim's register dump deleted]
>-> 
>-> E1 F1 M0 Q0 T V1 W0 X1 Y0 &P0 &T4
>-> 
>-> S50=000 S51:254 S52:002 S54=000 S55=000 S56=017 S57=019 S58:000 S59=000
>-> S61=150 S62=003 S63=001 S64=000 S65=000 S66=000 S67=000 S68=255 S69=000
>->
>-> S110:000 S111:030 S112=001
>-> S120:016 S121=000 S130=002 S131:001
>
>Is it really a good idea to turn off ALL flow control?  I have my S58 set to
>"002" for Full RTS/CTS flow control.  If I can speed throughput without data
>loss, please let me know.
>

Actually the answer is both "No, it's not a good idea", and "Yes it may be
a very good idea".  The answer for your installation depends on exactly
what kind of calls you receive and what flow control your system can handle.

Turning all flow control off can be a very bad idea for interactive use
in PEP mode and with other error corrected connections.  Actions like
listing a large directory or redrawing a screen (^L in vi) can overflow
the modem's buffer.  If the modem can't make the computer pause (flow
control is completely disabled), then some of the data will be lost.

However, it should be noted that Tim's settings have the port speed unlocked 
(S66=0), therefore the slower speed connections probably won't overrun the
modem's buffer - the modem can empty itself as fast as the computer pumps
data in, so no overflow occurs.  In PEP mode, there is a greater chance
of losing data, but Tim's callers may not have a problem with it.

Now let's look at UUCP use.  The UUCP "g" protocol definitely rules out
XON/XOFF flow control in the modem.  It just won't work when the modem is
reacting to XON and XOFF characters.  That leaves RTS/CTS flow control, or
none at all.  Tim's setup is on a Macintosh, I believe, and he may not be
able to give up the DTR and DCD signals for use as RTS and CTS.  Therefore
he elected to disable flow control entirely and use a configuration that
reduces the need for flow control (S66=0).

If your system can support RTS/CTS flow control, then by all means use
it!  The modem will stay transparent to UUCP transfers, yet still have
control over the data flow during your interactive sessions.

I also see that Tim has his modem set to Q0 - an extremely unusual setting
for a Unix system.  Getty generally needs the modem to use Q4.  So you see 
that modem configurations posted on the net may reflect the special needs 
of the article's author.  You may not want to duplicate their configuration 
unless you have exactly the same needs as they do.

One last side note on Telebit modems and UUCP transfers:  There is an
alternate flow control setting that may help.  Setting S58=0 and S68=3
will let the modem stay transparent to XON and XOFF for UUCP transfers,
while allowing the modem to use XON/XOFF flow control to make the
computer pause.  This may not work for everyone.


>David A. Snyder @ UE&C - Catalytic in Philadelphia, PA

-- 
 .------------------------------------------------------------------------.
 |  Greg Andrews   |       UUCP: {apple,amdahl,claris}!netcom!gandrews    |
 |                 |   Internet: gandrews@netcom.COM                      |
 `------------------------------------------------------------------------'