Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!decvax!ittvax!dcdwest!sdcsvax!sdcrdcf!hplabs!sri-unix!gwyn@BRL-VLD.ARPA From: gwyn@BRL-VLD.ARPA Newsgroups: net.unix-wizards Subject: Re: DC3/DC1 flow control Message-ID: <1730@sri-arpa.UUCP> Date: Sat, 7-Jul-84 19:04:18 EDT Article-I.D.: sri-arpa.1730 Posted: Sat Jul 7 19:04:18 1984 Date-Received: Tue, 10-Jul-84 07:39:46 EDT Lines: 55 From: Doug Gwyn (VLD/VMB) 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).