Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-tgr!tgr!root%bostonu.csnet@CSNET-RELAY.ARPA
From: root%bostonu.csnet@CSNET-RELAY.ARPA (BostonU SysMgr)
Newsgroups: net.unix-wizards
Subject: Re: lost characters in serial I/O
Message-ID: <2145@brl-tgr.ARPA>
Date: Tue, 15-Oct-85 14:18:15 EDT
Article-I.D.: brl-tgr.2145
Posted: Tue Oct 15 14:18:15 1985
Date-Received: Thu, 17-Oct-85 02:26:29 EDT
Sender: news@brl-tgr.ARPA
Lines: 48


>From: jwp@uwmacc.UUCP (Jeffrey W Percival)
In summary: a file is sent over a serial line in a very simple manner,
chars are lost although XON/XOFF is enabled. Similar behavior is seen
with typing at the system at very high loads.

1. Check that the remote system really is sending the XOFFs

2. Check that the local system (or terminal) really is stopping
when an XOFF is received.

3. Check the points at which the XOFF is sent in the kernel (eg. tty.c)
which is going to be a little below where the system decides to throw
things away (it gives a little margin to let the other side stop sending.)
Raise the margin to allow more time for the other side to respond.

4. If the file you are sending does not have a newline after 255 (or
whatever the manifest limit is in your kernel) characters things start
getting thrown away (TTYHOG.) Putting the remote end into CBREAK may
help this (and will probably speed up the kernel's ability to pass
thru chars as a lot of code checking for things like rubouts is
bypassed when CBREAK'd, tho I have never measured this. What you really
need here is the SYSV TERMIO stuff to suppress making things worse with
lots of context switches.)

5. If you are going through some sort of switch and it buffers and
it does not respond to XOFF's (just passes them through) you might be
in trouble as it will continue pouring in chars waiting in the switch
although the remote has heard the XOFF, not likely but a guess.

6. Write something trivially more sophisticated that ACKs each time a
line is read and teach the other side to wait, lockstepping in each
line. Or put a delay after each line sent (this is tricky.)

7. Shut off echoing when transferring (stty -echo;cat > file;stty echo)
I have seen this cause all sorts of troubles.

8. Use something like KERMIT which is quite expert in all these problems
and is free and probably available for both sides (certainly UNIX.) It
has the added advantage of not only flow-controlling but also error checking.

9. As far as user's typing goes, either try to reduce the load, try allocating
more memory for clists in the kernel or make sure user's terminals are set
up to refuse keyboard input if they hear an XOFF (VTxxx's will do this),
this sounds like an extreme situation if you don't trace it down to a bug
somewhere.

	-Barry Shein, Boston University