Path: utzoo!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!caen!news.cs.indiana.edu!msi.umn.edu!cs.umn.edu!quest!zeno!gene
From: gene@zeno.mn.org (Gene H. Olson)
Newsgroups: comp.unix.sysv386
Subject: Re: Equinox question
Message-ID: <1991Mar9.090753.6901@zeno.mn.org>
Date: 9 Mar 91 09:07:53 GMT
References: <27B79130.5C72@telly.on.ca> <1991Feb13.170319.13308@virtech.uucp> <1991Feb15.165755.3231@pcserver2.naitc.com> <1991Feb20.202915.21242@eci386.uucp> <1991Feb21.142804.26980@virtech.uucp>
Organization: Smartware Consulting
Lines: 56

cpcahil@virtech.uucp (Conor P. Cahill) writes:
>Remember that there is a built-in flow control in UUCP (that 8 packet
>window), so you don't need hardware flow control on top of it unless
>your recieve buffers cannot hold 8 packets.

Remember that you may not be interfacing to the modem at the same
speed the modem transmits.  If that happens, and you are using a large
window size, you will find the data backing up in the transmit buffer
of the transmitting modem.

If the transmitting modem doesn't have enough buffer space, it might
be forced to discard the data.  I haven't seen modems back up data
with a window size of 3, but with a window size of 7 I see them flow
controlling like crazy.

I work for DigiBoard.  We run our internal modem lines as fast as
possible (usually 19200 or 38400) and use hardware flow control
to keep the computer from overrunning the modem buffers.

The only time I see problems is on modems that drop CTS whenever
RTS is dropped.  RTS from the host computer means that the input
buffer is nearly full, and the modem should stop sending data until
the host program can consume the data.  CTS tells the host system
not to send more data.  If the modem drops CTS just because RTS is
low, you may find the host program stopped from transmitting because
CTS is low, and unable to receive data (to raise RTS) until this
occurs.  Then you get a lockup condition.

To see if you are susceptable to this sort of lockup, I suggest you
hook up a breakout box or RS232 tester and watch it closely.  If
you see CTS regularly drop with RTS, you have a potential problem.

With all the better intelligent serial cards the input buffer is
considerably larger than the regular clist line discipline size
of 192-256 bytes.  So generally with UUCP you never have to slow
the flow of receive data.  Almost all the time you can live with
CTS flow control only.

There is one circumstance where RTS flow control is very important.
There are some versions of CU that are terrible CPU hogs;  they
appear to do single character tty reads and writes.  If you dial out
with CU and start receiving data, you'll saturate your host CPU right
away and data will back up in the tty receive buffer.  On any long
transfer (eg ~%take) even a large buffer will eventually overflow,
and you'll lose big chunks of data.  If you want to do those kinds
of operations, you'll need RTS.

My personal opinion (based on lots of customer calls) is that you
should always hook up RTS and CTS on high speed modems.  If your
modem vendor or serial port vendor has problems making it work,
its time to look for another vendor.
_________________________________________________________________________
   __ 
  /  )                Gene H. Olson             uunet!digibd!gene
 / __  _ __  _        Senior Staff Engineer
(__/ _(/_//_(/_       DigiBoard, Inc.           gene@digibd.com