Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: casey@gauss.llnl.gov (Casey Leedom)
Newsgroups: comp.sys.sun
Subject: Re: Hardware flow control under 4.1 and higher
Keywords: Miscellaneous
Message-ID: <1427@brchh104.bnr.ca>
Date: 22 Jan 91 07:58:16 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 28
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v10n12
X-Sun-Spots-Digest: Volume 10, Issue 29, message 3
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

| From: auspex!guy@uunet.uu.net (Guy Harris)
| 
| The only *software* flow control SunOS implements is XON/XOFF flow
| control; it doesn't implement bi-directional RTS/CTS flow control (wherein
| the Sun can drop RTS to ask the device to stop sending data) - that
| wouldn't be hardware flow control, 'cuz the hardware won't do it
| automatically.

I can't quite tell, but it sounds like you're complaining about RTS/CTS
flow control and not Sun's hardware.  RTS/CTS flow control is *far better*
than XON/XOFF flow control for a number of reasons:

1. RTS/CTS flow control enables you to set up a completely transparent
   channel.

2. If an XON or XOFF is missed for any reason in software flow control,
   the channel can lock up.  (This won't happen with RTS/CTS signaling unless
   the hardware is designed particularly badly.)

If full receiver buffers can't trigger lowering RTS, the problem sounds
like it's with the Sun hardware, not the signalling mechanism.

But problems like this aren't unique to Sun.  Unix tty drivers have never
been very good.  One of the reasons we finally gave up entirely on hooking
our high speed modem pool to a Unix machine and bought a good terminal
server instead.

Casey