Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.hawaii.edu!news.uoregon.edu!hunter.premier.net!news-res.gsl.net!news.gsl.net!news.mathworks.com!newsfeed.internetmci.com!in2.uu.net!EU.net!usenet2.news.uk.psi.net!uknet!usenet1.news.uk.psi.net!uknet!dispatch.news.demon.net!demon!awfulhak.demon.co.uk!awfulhak.demon.co.uk!awfulhak.demon.co.uk!not-for-mail
From: brian@awfulhak.demon.co.uk (Brian Somers)
Newsgroups: comp.unix.programmer,comp.unix.bsd.freebsd.misc
Subject: Re: How prevent character loss on SIO?
Followup-To: comp.unix.programmer,comp.unix.bsd.freebsd.misc
Date: 19 Aug 1996 15:50:20 +0100
Organization: Coverform Ltd.
Lines: 109
Message-ID: <4v9uvc$h0@anorak.coverform.lan>
References: <4urf05$fsg@fu-berlin.de>
NNTP-Posting-Host: localhost.coverform.lan
X-NNTP-Posting-Host: awfulhak.demon.co.uk
X-Newsreader: TIN [version 1.2 PL2]
Xref: euryale.cc.adfa.oz.au comp.unix.programmer:41777 comp.unix.bsd.freebsd.misc:25722
Gunther Schadow (gusw@zedat.fu-berlin.de) wrote:
: I have go a big problem with serial line IO. I am loosing characters
: when there is high load on the machine, and I have no clue what to do.
: The problem is that the lines are either 3-wire (via glas fibers) or
: the other side (to which I have no influence) just doesn't use hard
: flow control. Now I thought that by enabling the IXON and IXOFF bits I
: could enable soft flow control, but I fear that the TTY device just
: doesn't send a STOP character when it's buffer is full, or, it comes
: too late to handle the interrupt from the SIO to read the data before
: this is overwritten?
: I need some help from someone who has some more TTY experience (seems
: like networking experience is more en voge nowadays, and I would so
: much like to dump the RS232 shit into the trashbin #@!*) To be more
: specific:
Na - RS232 is good.... slow but good.... Networks may be
better, but UARTs are simpler ! PC-Intern - it explains about UARTs.
: 1. is the IXOFF sending of a STOP character handled automatically
: by the SIO device driver?
Yep.
: 2. if yes, then would hard flow control improve the situation? I mean
: -- suppose I could use hard frow control, would the character loss on
: times of high system load be avoided? (i guess no)
Yep. Hardware flow control should eradicate your problems.
: 3. would FIFO chips *fix* this problem? Right now we use 81450 UARTs
: but the *550 would require to change the motherboard.
: 4. BTW: is a faster board/CPU and memory upgrade necessary? I can't
: believe that serving just two serial lines requires a RISC
: processor?
Both 3. and 4. would help, but not necessarily remove the problem. The
*100% correct* way is option 2. What happens is, machine A sends to
machine B. Bit 1,2,3,4,5,6,7,8,parity. It sends again ('cos it's
transmit buffer is empty and the UART interrupts). Bit 1,2,3,4,5,
6,7,8,parity. All this stuff disappears into the UART as far as the
sender is concerned. If the receiver hasn't read the receive character,
it'll get overwritten with the next character. The receiver (if it checks
the UART error byte) will see that it had an overrun of one or more
characters..... this'll probably end in an error in some log file (syslog
on U**x).
With an 8250 or 16450 UART, the driver must read the incomming byte after
the interrupt happens (on recepit of the last bit) and before the receipt
of the next byte. If it doesn't get there in time, it gets an overflow.
With a 16550, you set the UART up to interrupt after the receipt of
between 1 and 14 characters. The driver then reads all the received
characters. The driver must do it's read reasonably quickly - before
you fill the remaining 2-15 characters. It has much more time than the
8250/16450 case, but can still overflow.
With a fast CPU, the characters can be read before they get overwritten.
Fast hardware can overcome problems with badly written/configured
software :)
With software flow control, the receiving application (the tty driver I
believe) sends ^S to tell the other side to stop transmission 'cos it's
buffer is full - the application hasn't read anything 'cos it's busy)
and ^Q to restart. By the time the ^S has been sent, the buffer may
already have been overrun.
With hardware flow control (the *correct* way), two extra physical
serial wires are used. When the receiving UART gets a byte and has no
room in the receipt buffer, it raises one of these lines. The other side
stops sending. The application & tty drivers need to do nothing. If
the application doesn't read, the tty driver doesn't read. If the tty
driver's buffer is full, the interrupt handler doesn't read. If the
interrupt driver doesn't read, the CTS (Clear to Send) bit stays low. When
the application eventually reads, the tty driver emptys and reads from
the UART receive buffer. This raises CTS and tells the other side things
are ok.
: 5. Currently the SIOs are served by two quite sizable C++ programs
: that are performing numerous network communications on behalf of the
: serial communication, is a restructuring of the system required to
: make the SIO service faster?
Modifying user-level programs should not help unless you aren't "read"ing
very often. This can be addressed either with software flow control or
by making the application "read" more often. But, of course, HW flow
control is better !
: I guess that the answer on each of these question is ``yes, sure, fast
: hardware -- less problems'', but I need to know what is really
: required and what is just a ``nice to have'', and what I could
: improve on the software side.
Interrestingly enough, Dell are now selling a 200MHz PPro w/ 1Mb IDE
disk, 2Mb S3 card, 16Mb memory, 8speed IDE CDrom and 15" monitor for
#1445 here in the UK. Memory upgrades should be bought from somewhere
else (Dell charge #200 for 16Mb upgrade, Thame sell 16Mb simms for #64...).
Of course, 16550 UARTs are standard.
What I'm saying is that if you've spent some time resolving this problem,
it's probably cost your company more than it would forking out for the
decent hardware ?????? If you really want to solve the problem for good,
tell "the other side" that they are not supplying a workable service (HW
flow control) - if you're in a position to :)
--
Brian <brian@awfulhak.demon.co.uk>
Don't _EVER_ lose your sense of humour....