DC3/DC1 flow control

[gwyn at BRL-VLD.ARPA]

From:      Doug Gwyn (VLD/VMB) <gwyn at BRL-VLD.ARPA>

Here is how to determine the amount of terminal buffering required
at 19200 baud using silo alarms:

19200 bit/sec / 10 bit/char = 1920 char/sec

10^6 usec/sec / 1920 char/sec = 520 usec/char

A typical silo (DZ11, DH11) has 64 chars multiplexed from 8 lines, with
alarm when 32 chars are in the silo.  Usually the driver is too stupid
to quickly scarf up all chars+line_info and check for DC3s among them,
so there may be up to 32 chars processed (put on input queue) per
multiplexer before the DC3 is acted on.  This gets much worse if there
are several multiplexers; for example 64 lines is typical:

64 line / 8 line/multiplexer * 32 char/multiplexer = 256 char

Input char handling time varies; let's be reasonable and allow 64
microseconds per char:

256 char * 64 usec/char = 16384 usec

There is some interrupt overhead (1-8 interrupts) which is typically
less than one char transmission time, so let's ignore it.  Let's
also ignore higher-priority interrupts from things like card readers,
although in practice a safety margin needs to be allowed for these.

(Since input silos do not necessarily trigger the alarm frequently,
silo alarm-driven device drivers typically also empty the silos
periodically, say every clock tick:

10^6 usec/sec / 60 tick/sec = 16667 usec/tick

This is close to the time required to handle all the input chars on
64 lines if silo alarms were being triggered.)

16384 usec / 520 usec/char = 32 char

To this must be added the 2 chars that may already be in each UART
in both the receive and transmit channels, plus a 1-char margin for
transmission phase offset, for a total of

32 char + 4 * 2 char + 1 char = 41 char

Therefore a terminal needs to accept 41 chars after it decides to
send a DC3 in order to avoid possible overrun due to delay in a silo
alarm-driven multiplexer device driver.  I personally would make this
64 char since that is the next power of two.

The VT100 sends DC3 when there are 32 buffer slots left, which means
that it does not work right with this type of device driver.  I can
confirm this from practical experience also, although on fast CPUs
such as the PDP-11/70 the problem rarely occurs (for one thing, the
input silos are seldom full).