MORE INFORMATION
Flow Control
Flow control is a way for a modem to tell the computer to stop sending
data to it through the RS-232 cable. (The reverse is also true: the
computer also tells the modem when to stop sending. We are looking only
at one side here.) For example:
DTE DCE DCE DTE
Terminal---------Modem------Z-------Modem----------Terminal
9600 2400 9600
Assume you set your data terminal equipment (DTE) to 9600 bps so you
can get better performance from the modem (that is, the modem is always
busy and doesn't wait on the terminal for more data), but the modem
is capable of only 2400 bps over the phone line (the data communication
equipment, or DCE, rate or link rate). Most modems have some small internal
buffer, so when the terminal starts sending data to the modem at 9600 bps
the modem puts the data in a FIFO buffer and begins transmitting data over
the phone line. Because of the difference in DTE and DCE rates, the modem
buffer begins to fill. When it reaches a certain level, the modem uses
flow control to tell the terminal to stop sending. When the buffer reaches
a certain low level, the modem tells the DTE to start sending again.
Hardware Flow Control
Hardware flow control (or RTS\CTS) uses an "out of band" technique, meaning
that the control signal has a special line outside the data channel. With
full duplex, the modem drops CTS (clear to send) to tell the terminal to
stop sending. The modem sets CTS high again when its buffers reach the set
low level. RTS (request to send) is used by terminal (DTE) when receiving
data. RAS ignores hardware flow control; so if the modem has it turned on,
the modem could turn off CTS and RAS will just keep sending data, which
will be dropped when the modem buffer fills.
Software Flow Control
Software flow control (or XON\XOFF) uses an "in band" technique, meaning
that the control signal\command is sent along with the data stream. The
modem sends an XOFF character to tell the DTE to stop sending. XON tells
the DTE start again. These characters are mixed in with the data. RAS is
capable of sending and receiving data at the same time, but it doesn't
filter for the XON\XOFF characters. So if a modem is looking for these
characters, RAS might accidentally tell the modem to stop sending, then
never tell the modem to re-start (with XON) and communications fail.
XON - [CTRL Q] - ASCII 17
XOFF - [CTRL S] - ASCII 19
As stated above, RAS 1.0 and 1.1 do not support flow control. Do not
configure your modems to use flow control; it could cause RAS to fail.
If you cannot have flow control, set up the DTE-to-DCE rate to match the
DCE-to-DCE rate. This minimizes the chances of modem overflow, and means
that your high speed modems should be configured to autobaud, that is, the
DTE rate should be adjusted by the incoming DCE rate. This is configured by
default in RAS with all the supported high speed modems.
Almost all modems need flow control for modem data compression and error
correction.
Error Correction
Error correction is a modem technique used to ensure that blocks of
data are accurately received by the remote modem. Common error correction
schemes are MNP 4 and V.42 (preferred).
The process works this way: First, data to be transmitted is gathered into
a block of characters. Then, an algorithm generates a number based on the
block (a checksum) and attaches it to the end of the block. When the other
modem received the block, it performs the same algorithm and compares the
result with the sent checksum. If these values do not match, the receiving
modem tells the sender to retransmit the block.
Because a block of data may have to be retransmitted, modems store blocks
in a buffer until sure that the receiving modem has correctly processed it.
The modem must use flow control to keep the DTE from overwriting the frame
with new data. Because RAS does not respond to flow control, it may
overwrite a block that has not yet been acknowledged.
AsyBEUI, which is almost identical to NetBEUI, implements its own error
control. All LLC type 2 (connection oriented) frames must be explicitly or
implicitly acknowledged within a specified amount of time or AsyBEUI
retransmits them. If modem error correction retransmits a frame, then
AsyBEUI times out and retransmits the frame again, the unnecessary traffic
duplication slows things down, and generally confuses RAS.
The only reason to turn on error correction with RAS is to use data
compression (most modems require error correction for data compression).
If you want to use error correction, please see the excerpt from the
README.TXT file at the end of this article. In addition, you should do
the following:
- On both client and server, turn on hardware flow control on your
modem. Again, RAS ignores this but at least it won't interfere with
data transfer. Add the flow control command to the INIT command in the
MODEMS.INF file.
- On both client and server, turn on error correction on the modem.
Use v.42 if available. Add the AT command to the COMMAND = line in
MODEMS.INF file. See the RAS manual for more information on editing
MODEMS.INF.
Data Compression
Data compression allows modems to convey more information in a given block
of data, thus increasing throughput and reducing transmission time. Common
compression routines are MNP 5 and V.42bis (the preferred standard--it's
30 percent faster, and more commonly used).
Most modems won't let you turn on compression without error correction,
and thus flow control. It is not enabled by default, and generally should
not be used. If you want to try using it, please see the excerpt from the
README.TXT file at the end of this article. In addition, enable compression
on both the client and the server. Use V.42bis instead of MNP 5 if you can,
and add the command to the MODEMS.INF INIT command for your particular
modem type.
Compression can increase RAS performance, if you can avoid the pitfalls
that can occur because of lack of flow control. If it does not work, there
is little you can do until flow control is implemented in RAS.
If a compression routine can achieve a 2:1 ratio (2 bytes of information
with every 1 byte sent over the modem link) then a modem with a link rate
of 9600 bps should receive data from the DTE at 19,200 bps (giving you an
effective throughput of 19,200 bps). Anytime the terminal sends data faster
than the modem can transmit it over the link, you may overflow the buffers
if you have no flow control (even with compression). Increase the MAXBAUD
parameter (in MODEMS.INF) to the maximum throughput rate expected, then
reinstall your modem through Setup to modify the baud rate in COMDEV.INI.
See the README.TXT excerpt below for more information.
Compression methods are generally based on techniques that replace
frequently occurring characters with some kind of token representation
that is shorter than the original data. Compression techniques need to
examine a group of characters in order to determine frequency, so it works
better if you can keep the modems buffers relatively full. Turning on LAN
Manager raw mode helps, because it transfers large files in blocks of 64K.
See the README.TXT file below for more information.
Generally, if you have a large enough buffer on your modem, you can avoid
overflow situations. See your modem manual for information on buffer size.
A 3,000 byte buffer is a fairly safe size.
Excerpt from RAS README.TXT
Before Enabling Error Control and/or Compression, Check to See That:
- Your computer can accommodate the higher baud rates required for
compression. Make sure your Remote Access client workstation has a
80386 or higher processor and also has 16450 or higher serial port
UART chip installed.
- Your Remote Access server has a multiport adapter installed,
relieving the main processor of some of the interrupt processing
load.
- You have identical or compatible modem types on the server and
client workstations.
- Your telephone line has little or no static. Static minimizes the
effectiveness of redundant error control.
Enabling Modem Error Correction and/or Compression
- Set the MAXBAUD parameter for your modem in the MODEMS.INF file to
the maximum baud rate at which you will be communicating. Valid
baud rates are 1200, 2400, 4800, 9600, 19200, and 38400.
- For MS-DOS workstations running LAN Manager Enhanced, change digit
14 of the WRKHEURISTICS line in LANMAN.INI from 1 to 0. This causes
the LAN Manager workstation to transfer data in 64K blocks. This
large block size ensures a smooth, constant flow of data from the
computer to the modem. The modem's compression buffers will fill up
quickly, thereby minimizing data transmission delays.
- For MS OS/2 workstations, change digit 11 of the WRKHEURISTICS line
in LANMAN.INI from 0 to 1. This causes the LAN Manager workstation
to transfer data in 64K blocks. This large block size ensures a
smooth, constant flow of data from the computer to the modem. The
modem's compression buffers will fill up quickly, thereby
minimizing data transmission delays.
- Increase the value of the MAXDYNMEM parameter in the LANMAN.INI
file of the Remote Access server to accommodate Remote Access
clients that use a large frame size for data transfer. There is a
trade-off between gaining faster file transfer, and the amount of
memory required on the Remote Access server. You will have to
increase the amount of memory installed on your Remote Access
server. For more details on tuning the Remote Access server, see
Chapter 6 in the "Microsoft LAN Manager Remote Access Service
Administrator's Guide."
Note: Microsoft cannot guarantee proper functionality at baud rates
higher than those indicated in the default MAXBAUD = line of your
MODEMS.INF file.
Windows NT
RAS for Windows NT support both hardware and software flow control, error
correction, and data compression.