Modem to Modem Flow Control
Jeffrey Rhodes
> Can someone explain how modems implement flow control between each
> other? For example, let's say I have modem A with a serial port speed
> of 115200 which dials into modem B with a serial port speed of 19200
> and connects with a carrier of 28800. The system connected to modem A
> starts blasting data to modem A at 115200, modem A starts sending data
> to modem B at 28800, modem B starts sending data to the system
> connected to modem B at 19200. Soon system B stops data flow (either
> via hardware or XON/XOFF). How does modem B tell modem A to stop
> sending data and later tell it to start sending again?
I saw some posts on this subject, but I don't think I saw a good
answer. I was hoping someone could explain flow control alot better
than I can, but I'll take a try.
I think the answer to the question lies in the fact that when the
modems initially connect and negotiate what speed they will use, modem
B will force the connection to 19,200 or less. If this is correct,
there is no need for modem-to-modem flow control. If the modems are
both V.34 modems, the connection rate could be 28,800 because V.34
uses some kind of HDLC protocol where information is encoded in
packets or frames (I think). This provides flow control since only so
many packets or frames can be sent without being acknowledged. Again,
there is no need for any kind of XON/XOFF thing between modems.
I think I read that PPP protocol connections to an Internet Service
Provider are better if you turn off the flow control and error
correction of ARQ, since this only thrashes with the same PPP
functions at a higher layer?
Maybe someone will correct my misconceptions, but in general, I think
today's protocols and modems provide modem-to-modem flow control
without XON/XOFFs. Of course, hardware RTS/CTS flow control between
each PC and its modem is needed to run 115,200 into a modem in the
first place, and this is needed to deliver data at a higher DTE rate
than the transmission rate so that compression techniques will offer
any benefit. Theoretically, V.42 can give >28,800 bps with
compression, but only when much >28,800 bps are delivered by the DTE.
Jeffrey Rhodes
John Eichler
I might be able to add a little something to what Jeffrey Rhodes
wrote.
There are two rates which must be considered when talking about modem
communications. One is the rate at which the computer itself
feeds/accepts data to/from the modem. The other is the rate at which
the modems actually talk between themselves.
Concerning the first rate. The values of 2.4K, 4.8K, 7.2K, 9.6K, 19.2K,
38.4K, 115.2K etc. are based upon the data rates of serial ports on most
computers. There are set recommended frequencies that are usually used
to clock the UART (Universal Asynchronous Receive Transmit) chips.
These rates are simply the rates at which the modem's DSP communicates
with the computer itself. It makes no difference which rate is chosen
as long as your computer is capable of accepting data at the designated
rate.
There are two primary considerations with regards to this.
First, a buffered UART must be used (such as the 16550) because many
of the newer operating systems are not capable of responding to I/O
requests rapidly enough so the input in particular must be buffered
from the modem until the OS can get around to reading it in. The
16550 can buffer 16 bytes of input (and output) and thus a computer
can read in several bytes in a burst-type mode. To coordinate the
flow between the computer and the modem this is where flow control is
normally used. There are a couple of primary ways this is
accomplished. One is by embedding certain codes (xon/xoff) within the
byte stream feed to/from the modem. The others are using hardware
signals such as the DTR/DSR pair or the CTS/RTS pair.
Second, if data compression is used (i.e., that provided by the modems
themselves), the actual data rate between the computer and the modem
can effectively be 3 or 4 times the rate at which data is transmitted
by the modem. For example, assumming that two modems are
communicating at 14.4K bps with compression implemented, the sending
and receiving computers might have to transmit/receive at 4 times this
rate (i.e., 57.6K bps) to fully utilize the transmission channel.
This puts a burden on the computers to be able to keep up with the
faster rate. This also is why one should set the transmission speed
to/from the modem at a much higher rate if they are going to turn on
data compression within their modems.
Now the rate at which the modems talk between themselves is, as
Jeffrey states, usually determined by the modems themselves. Most
modern modems implement a 'fall-back' scheme at which they negotiate
between themselves which is the rate to be used. Generally they first
try at the highest rate possible and if this rate won't work, they go
to the next lower rate and try that. (It may be noted that some modem
protocols actually will dynamically adjust the rate of transmission
depending on line quality and error rates encountered.) These rates
are the transfer rates defined by the ITU in its various standards.
Although it is possible with many modems to specify that a particular
connection speed should be used, it is usually better to let the modems
determine it themselves particularly over a public switched telephone
network. Just specify the highest rate at which the modem can operate
as the starting point.
The main area of confusion when talking about speeds is usually
extrapolating the modem transmission rate from the computer to/from
modem rates. The clocking of the UARTs transmitting data between a
computer and a modem is completely asynchronous from the speed at
which the modems communicate between themselves. (This is not true
for binary synchronous communications which is a horse of a different
color and generally not used by most folks.) Don't get the speeds
mixed up. Just make sure that the computer that is being used to talk
to the modem has a higher rate specified than the modem is capable of
receiving data at. For transmitting data it doesn't matter since the
modem will just transmit meaningless info just to keep the connection
alive. But for receiving, note the comments made above.
I hope this might clear up a little of the confusion in this thread.
John Eichler
James Carlson
> there is no need for modem-to-modem flow control. If the modems are
> both V.34 modems, the connection rate could be 28,800 because V.34
> uses some kind of HDLC protocol where information is encoded in
> packets or frames (I think). This provides flow control since only so
> many packets or frames can be sent without being acknowledged. Again,
> there is no need for any kind of XON/XOFF thing between modems.
Pretty close. All high-speed (>=9600bps) modems use synchronous links
between the modems. On top of this, they use LAP-M (which is an
HDLC-based protocol) and V.42 or V.14 to adapt asynchronous traffic to
the modem's synchronous interface.
The LAP-M protocol is basically a reliable transport protocol which
uses retransmission timers and sequence numbers to achieve
reliability. In this protocol, flow control is done by having the
receiver indicate that it's willing to receive more data, and not
necessarily by a "flow off" message as with XON/XOFF. (Though,
confusingly, V.42 does provide a way to carry RS-232 signals
end-to-end. Sigh!)
> I think I read that PPP protocol connections to an Internet Service
> Provider are better if you turn off the flow control and error
> correction of ARQ, since this only thrashes with the same PPP
> functions at a higher layer?
PPP does not do flow control or error correction at all. TCP, which
is one of many, many protocols which can run over PPP, does do both
flow and congestion control. Use of error control protocols on top of
one another is generally a bad idea if the error recovery time of the
lower level is similar to the normal round-trip-time.
This does mean that it's *sometimes* a bad idea to run TCP over a PPP
link with error control turned on. Unfortunately, no solid rule can
be made, and leaving error control on in the modems *usually* does no
harm.
> Maybe someone will correct my misconceptions, but in general, I think
> today's protocols and modems provide modem-to-modem flow control
> without XON/XOFFs. Of course, hardware RTS/CTS flow control between
> each PC and its modem is needed to run 115,200 into a modem in the
> first place, and this is needed to deliver data at a higher DTE rate
> than the transmission rate so that compression techniques will offer
> any benefit. Theoretically, V.42 can give >28,800 bps with
> compression, but only when much >28,800 bps are delivered by the DTE.
Right. Note, though, that 28.8Kbps at the modem link level (DCE) is a
synchronous data rate, and 115.2Kbps on the DTE is an asynchronous
data rate. The two are not directly comparable. 28.8Kbps DCE is
about 3600cps (not including overhead). 115.2Kbps DTE is 11520cps
(assuming 8 bits, no parity, one stop bit).