From: clewis@ferret.ocunix.on.ca (Chris Lewis)
Newsgroups: comp.sys.3b1
Subject: Re: Fix for interactive use/19200 baud serial line
Keywords: 3B1 7300 19200 serial
Date: 14 Sep 92 16:18:21 GMT
Organization: Elegant Communications Inc., Ottawa, Canada

In article <1992Sep13.123204.11032@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (Don Nichols (DoN.)) writes:
>>The "stty nl1" makes any output of a newline be followed by an arbitrary
>>pause.  I *think* this pause lets the hardware catch up and get the cursor
>>where it belongs before processing more output.  Any confirmations/denials?

>	That is essentially correct.  The bottleneck is that the inputs (and
>outputs) generate an interrupt for each character sent/received, and this is
>a *major* load on the machine.  The result is that the machine doesn't have
>enough time to fetch the character from the input buffer before the next one
>arrives to overwrite it (after a continuous stream of characters have been
>flowing for a while).  The hardware flow control only works in one
>direction.  It works when the other device requests a pause in the flow, but
>it cannot request a stop when *it* needs to catch up.  The code is present
>in the source, but is commented out, for some reason - or so I am told.

As a FYI: *outgoing* flow control is usually implemented in hardware.  The
flow control line is usually directly connected to the UART.  When it gets
deasserted, the UART will stop almost instantaneously.

[I say "almost" because the UART has to wait until the current character
being transmitted has been sent.  Ie: as soon as the UART becomes ready
to send the next character, the transmit hardware gets stopped.]

The only way software gets involved is to make sure that closes on the
line don't hang because there's still characters in the clists (or possibly
in a UART fifo.  Most uarts have a two character fifo (or one plus current
transmitting character).)  On machines with buggy serial drivers, the leading
cause of unkillable zombie processes is where the close hangs because it's
waiting for the last characters to disappear from the output queue, but
the serial device is flowcontrolled (or sometimes carrier-detected) off and
those characters stay there forever.

Incoming flow control is more complicated - the software has to detect
when its clists are about to overflow, and deassert the flow control in the
other direction.  Plus worry about driver hang etc.

>	There are those who deny that there is a problem with the flow
>control, or even with 19200 baud, but your experience shows (again) that
>there is.  Typical uucp exchanges are using short ehough packets, and
>acknowledgement is required after three, so that there are usually enough
>pauses for that to work - unless the ethernet board is loaded in operating,
>in which case the uucp fails at a spectacular rate at 19200, to the extent
>that I usually get better throughput at 9600 baud, since I *do* keep the
>ethernet board loaded and running.

Ie: except under high interrupt loading from hardware with higher priority
(or long interrupt-disable time), the 3b1 is fast enough to *service* the
interrupts on incoming 19200, but if the clists get full, it can't find any
room to put the characters, and you lose them.

Clists tend to be about 256 characters.  UUCP g protocol with its windows
of 3 64-byte packets (plus 6 bytes of overhead apiece if I remember correctly)
will fit in the clist.  Longer packets, or bigger windows (eg: 7,64 or 3,128)
won't.  As long as *one* packet will fit in the clist, UUCP will work, albeit
very slowly and possibly likely to drop because it'll run into trouble
with retransmitted packets.  If you're using packets that are too big to fit
in the clist, it won't work at all.

I run all of my UUCP at 19200 (fixed DTE rate on the modem) and it works
quite well - with 3,64, I often get incoming rates of >1200 characters
per second (this is sustained thru-put on big files).  Which is pretty good.
This appears to be pretty close to the maximum of V.32bis (without any
compression) thru 19200 lines.

On a outgoing only link, with UUCP f protocol, I see reliable speeds up to
1800 cps, but on incoming, it fails a lot on largish files.

What I would really like is a serial port that goes to 57Kb that flow
controls properly.  Then I could get rates like 3500 or even 4000 characters
per second thru f protocol.

[Incidentally, I have my 5620 terminal connected to the 3b1 at 9600 baud.
Without flowcontrol, it wouldn't work spit.  I should really try upping
it to 19200 with hardware flowcontrol]

>	The delay option is a good one.  I hadn't thought of that.  Thanks.
>It is usually intended for printers which don't buffer, and need extra time
>for a carriage return to complete.  (There are few of those these days,
>thank God.

Yes, the delay option is a good one.  Another idea is what we use for
3b1->other machine cu-sessions:

	cu <machine> | tee /dev/null

I believe what this does is make the cu instance that's receiving characters
and sending them to your screen run buffered to tee, giving it a better
chance to keep up with the incoming characters.  I suspect that it's
also less annoying/jerky and overall faster than using stty nlx.

Without this, cu at 9600 to another machine drops characters like crazy.
-- 
Chris Lewis; clewis@ferret.ocunix.on.ca; Phone: Canada 613 832-0541
Psroff 3.0 info: psroff-request@ferret.ocunix.on.ca
Ferret list: ferret-request@ferret.ocunix.on.ca
Newsgroups: comp.sys.3b1,comp.sys.apollo,comp.sys.atari.st,comp.sys.sequent,comp.unix.aix,comp.unix.amiga,comp.unix.cray,comp.unix.sysv386,comp.unix.ultrix