Schauble@MIT-MULTICS.ARPA (07/07/84)
From: Paul Schauble <Schauble@MIT-MULTICS.ARPA> From utcsstat!geoff "My main objection to DC3/DC1 flow control is that it is a negative acknowledgement scheme and certain brain-damaged terminals such as the DEC VT100 contain insufficient buffering to allow them to operate at high speed, especially when using smooth-scroll (which is too slow in the VT100). The problem is worse if the terminal driver attempts to use silo alarms rather than taking interrupts immediately upon receipt of incoming characters. Perhaps you can settle a question for me. When running such a terminal driver at 19.2 kB, how much must the terminal be able to buffer after sending the DC3? Paul
gwyn@BRL-VLD.ARPA (07/08/84)
From: Doug Gwyn (VLD/VMB) <gwyn@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).