Hardware manual

Now lets consider an example of the operation of flow control. Consider the flow of bytes from the remote
computer at the other end of the phone line to the screen on the text-terminal that I'm sitting at. A real
text-terminal has a limit to the speed at which bytes can be displayed on its screen and issues a flow control
"stop" from time to time to slow down the flow. This "stop" propagates in a direction opposite to the flow of
bytes it controls. What happens when such a "stop" is issued? Let's consider a case where the "stop" waits
long enough before canceling it with a "start", so that it gets thru to the remote computer at the other end of
the phone line. When it gets there it will stop the program at the remote computer which is sending out the
bytes.
Let's trace out the flow of this "stop" (which may be "hardware" on some links and "software" on others).
First, suppose I'm "capturing" a long file from the remote computer which is being sent simultaneously to both
my text-terminal and to a file on my hard-disk. The bytes are coming in faster than the terminal can handle
them so it sends a "stop" out its serial port to a serial port on my PC. The device driver detects it and stops
sending bytes from the 8k PC serial buffer (in main memory) to the terminal. But minicom still keeps sending
out bytes for the terminal into this 8k buffer.
When this 8k transmit buffer (on the first serial port) is full, minicom must stop writing to it. Minicom stops
and waits. But this also causes minicom to stop reading from the 8k receive buffer on the 2nd serial port
connected to the modem. Flow from the modem continues until this 8k buffer too fills up and sends a different
"stop" to the modem. Now the modem's buffer ceases to send to the serial port and also fills up. The modem
(assuming error correction is enabled) sends a "stop signal" to the other modem at the remote computer. This
modem stops sending bytes out of its buffer and when its buffer gets full, another stop signal is sent to the
serial port of the remote computer. At the remote computer, the 8-k (or whatever) buffer fills up and the
program at the remote computer can't write to it anymore and thus temporarily halts.
Thus a stop signal from a text terminal has halted a program on a remote computer computer. What a long
sequence of events! Note that the stop signal passed thru 4 serial ports, 2 modems, and one application
program (minicom). Each serial port has 2 buffers (in one direction of flow): the 8k one and the hardware
16-byte one. The application program may have a buffer in its C_code. This adds up to 11 different buffers
the data is passing thru. Note that the small serial hardware buffers do not participate directly in flow control.
Also note that the two buffers associated with the text-terminal's serial port are going to be dumping their
contents to the screen during this flow control halt. This leaves 9 other buffers that may be getting filled up
during the flow control halt.
If the terminal speed limitation is the bottleneck in the flow from the remote computer to the terminal, then its
flow control "stop" is actually stopping the program that is sending from the remote computer as explained
above. But you may ask: How can a "stop" last so long that 9 buffers (some of them large) all get filled up? It
seldom happens, but it can actually happen this way if all the buffers were near their upper limits when the
terminal sent out the "stop".
But if you were to run a simulation on this you would discover that it's usually more complicated than this. At
an instant of time some links are flowing and others are stopped (due to flow control). A "stop" from the
terminal seldom propagates back to the remote computer neatly as described above. It may take a few "stops"
from the terminal to result in one "stop" at the remote computer, etc. To understand what is going on you
really need to observe a simulation which can be done for a simple case with coins on a table. Use only a few
buffers and set the upper level for each buffer at only a few coins.
Does one really need to understand all this? Well, understanding this explained to me why capturing text from
a remote computer was loosing text. The situation was exactly the above example but modem-to-modem flow
control was disabled. Chunks of captured text that were supposed to also get to my hard-disk never got there
because of an overflow at my modem buffer due to flow control "stops" from the terminal. Even though the
Serial HOWTO
4.8 Complex Flow Control Example 17