Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!mips!mips!sdd.hp.com!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: (386BSD) Modems and com ports
Message-ID: <1992Aug22.202524.18714@fcom.cc.utah.edu>
Keywords: internal or external?
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1992Aug20.171557.30071@watson.ibm.com> <1992Aug20.213721.4548@gateway.novell.com> <14226@auspex-gw.auspex.com>
Date: Sat, 22 Aug 92 20:25:24 GMT
Lines: 104
In article <14226@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
>>2) A UNIX write, once started, must run to completion before it may be
>> XOFed.
>
>In what sense?
>
>If the serial port device doesn't have DMA, and the main CPU hands it
>each character to be transmitted, one at a time, the driver can, if it
>receives a ^S, just stop handing the device characters until it gets a
>^Q.
>
>If the serial port device *does* have DMA, then, if a DMA operation can
>be halt and restarted later, or can be aborted and restarted from
>where it left off, the driver can, if it receives a ^S, just halt or
>abort the transmission, and restart it when it gets a ^Q.
In the sense of an interrupt driven transmitter. Luckily (or unluckily 8-),
most standard PC comm boards don't suport DMA unless they are a multiport
board. If there are DMA boards with on-board RAM, then the problem is
generally exacerbated by the fact that you download a block of characters
for output and forget about it. Unless part of the tty driver is downloaded
to the card (DigiBoard is the only manufacturer currently doing this, to
my knowledge), at least that many characters go out before an XOFF can be
acknowledged. If there is a lot of bidirectional traffic, both input and
output buffer can be filled, causing a tendency to process 2 times the buffer
size of characters before flow control is recognized.
Computone got around this problem (with technology from Arnet, their spin-off
competitor that they bought out) by putting flow control on the board. On
later ROM revisions you could even turn it off 8-) 8-). The problem with
this is, at speeds grater than 2400-4800 baud depending on system speed and
loading, you'd lose input characters (in-bound and out-bound flow control
were not seperable). This probem was alleviated, somewhat, on SCO systems,
when SCO went for 32 to 24 characters for their clist struct size. The
problem with this was that they didn't tell anyone until two minor revisions
later. The lucky manufacturers only needed a new driver to not lock up at
high character rates; the unluck ones needed new ROMs. The very unlucky ones
had soldered their ROMs and needed to replace boards. This killed two board
manufacturers outright and made things generally difficult, but tended to
reduce the overall problem by about 60% (24 vs 32 into 128 byte buffers,
with a potential for an extra clist full before flow control is effective).
>>The problem shared by any flow control whatsoever is lockup on line drop.
>>If the computer is ^s'ed, or !RTS or !CTS'ed, then the driver will wait
>>for the condition to be cleared. In most cases, this takes precedence
>>over a little thing like DCD dropping because of call waiting or a bad
>>connection.
>
>If so, the driver is probably buggy. It *should* manage - at least by
>default - to flush pending output, and wake up anybody waiting for the
>output queue to drain, if carrier drops.
This generally doesn't happen... the sleep-on address is not necessarily
accessable from interrupt level, where this should happen. In theory, yes,
it's possible, especially with multi-address sleeps (quote-unquote) such
as are used to implement poll() and select(). In practice, most serial
drivers just lock up until the next call.
In *actual* proctice, flow control tends to not be used at all, since it's
much better to have equipment that can have a throughput of 960 characters
a second for 9600 baud settings, and people don't tend to try to fool
themselves (look ma! 19.2!) when their actual throughput after flow control
is only 480-600 characters a second (I know, people will argue that 6000 baud
is better than 4800 baud. If your equipment supports it is a setting, fine).
This behaviour could be described as "buggy", especially if you are a VMS
user who tends to live or die by flow control, due primarily to DEC termials
after the VT220 being ROM-interpretive and unable to keep up with 960
characters a second, especially when doing screen manipulations like line
deletion, etc. The "good 'ol" Wyse 60 has this problem too, but people will
keep using it for it's other features "Sure it only goes 45 MPH, but *look*
at the tires!"
I've been working in async communications on UNIX systems (I was senior
programmer at Century Software, manufacturers of TERM) for over 7 years,
and networking for 4, and I can pretty much *guarantee* you that the vast
majority of UNIX serial drivers, *especially* the DMA ones, will lock up
under flow control eventually, even if everything is set up correctly (and
most users *don't* set everything up correctly, especially modem switch
settings).
When you are trying to come up with a general soloution to a problem, you
have to take into account the least common denominator. In this discussion,
that's that in band flow control is useless because it prevents binary
communications, and that out of band flow control (CTS/RTS) locks up many
drivers (Sun, SCO, ISC, etc.).
>Some tty subsystems are buggy in that fashion, but it is a bug....
It may indeed be a "bug"; I view it as such. That doesn't mean that it isn't
everywhere or that it doesn't need to be worked around for the general case.
Terry Lambert
terry_lambert@gateway.novell.com
terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
terry@icarus.weber.edu
"I have an 8 user poetic license" - me
-------------------------------------------------------------------------------