Hardware manual

transmitted to the modem or (other device connected to the serial port) which also has a fair sized (say 1k)
buffer. When the device driver (on orders from flow control sent from the modem) stops the flow of outgoing
bytes from the computer, what it actually stops is the flow of outgoing bytes from the large transmit buffer in
main memory. Even after this has happened and the flow to the modem has stopped, an application program
may keep sending bytes to the 8k transmit buffer until it becomes full. At the same time, the bytes stored in
the FIFO continue to be sent out. Bytes stored in the modem will continue to be sent out the phone line unless
the modem has gotten a modem-to-modem flow control stop from the modem at the other end of the phone
line.
When the memory buffer gets full, the application program can't send any more bytes to it (a "write"
statement in a C-program blocks) and the application program temporarily stops running and waits until some
buffer space becomes available. Thus a flow control "stop" is ultimately able to stop the program that is
sending the bytes. Even though this program stops, the computer does not necessarily stop computing since it
may switch to running other processes while it's waiting at a flow control stop.
The above was a little oversimplified in three ways. First, some UARTs can do automatic hardware flow
control which can stop the transmission out of the FIFO buffers if needed (not yet supported by Linux).
Second, while an application process is waiting to write to the transmit buffer, it could possibly perform other
tasks. Third, the serial driver (located between the memory buffer and the FIFO) has it's own small buffer (in
main memory) used to process characters.
4.8 Complex Flow Control Example
For many situations, there is a transmit path involving several links, each with its own flow control. For
example, I type at a text-terminal connected to a PC and the PC (under my control) dials out to another
computer using a modem. Today, a "text-terminal" is likely to be just another PC emulating a text-terminal.
The main (server) PC, in addition to serving my text-terminal, could also have someone else sitting at it doing
something else. Note that calling this PC a "server" is not technically correct but it does serve the terminal.
The text-terminal uses a command-line interface with no graphical display. Every letter I type at the
text-terminal goes over the serial cable to my main PC and then over the phone line to the computer that I've
dialed out to. To dial out, I've used the communication software: "minicom" which runs on my PC.
This sounds like a simple data path. I hit a key and the byte that key generates flows over just two cables
(besides the keyboard cable): 1. the cable from my text-terminal to my PC and 2. the telephone line cable to
some other computer. Of course, the telephone cable is actually a number of telephone system cables and
includes switches and electronics so that a single physical cable can transmit many phone calls. But I can
think of it like one cable (or one link).
Now, let's count the number and type of electronic devices each keystroke-byte has to pass thru. The
terminal-to-PC cable has a serial port at each end. The telephone cable has both a serial port and a modem at
each end. This adds up to 4 serial ports and 2 modems. Since each serial port has 2 buffers, and each modem
one buffer, that adds up to 10 buffers. And that's just for one direction of flow. Each byte also must pass thru
the minicom software as well.
While there's just 2 cables in the above scenario, if external modems were used there would be an additional
cable between each modem and it's serial port. This makes 4 cables in all. Even with internal modems it's like
there is a "virtual cable" between the modem and its serial port. On all these 4 links (or cables), flow control
takes place.
Serial HOWTO
4.7 Data Flow Path; Buffers 16