To combat such problems, the modem incorporates two separate methods of error correction, the Microcom Network Protocol (MNP) and the ITU-T V.42 (V.42) error correction protocol. In addition, MNP5 incorporates a data compression algorithm allowing data to be sent from modem to modem at around twice the normal speed. To further improve data throughput and reduce file transmission times, the modem incorporates the V.42bis data compression standard. This reduces the size of transmitted data by exploiting characteristics of the data to give compression ratios in the range 2:1 to 4:1 depending upon the predictability of the data.

The newer ITU-T V.42 LAPM procedure is considered as more robust than MNP, and has a more sophisticated and powerful data compression option in V.42bis, allowing much greater data throughput. The Microcom Network Protocol is provided for compatibility with older modems which are still in use.

Some recommendations and restrictions are placed on the use of error correction and data compression. Error correction cannot be used in V.21 (300/300 bps), V.23 (1200/75 bps and 75/1200 bps) or Bell 103 (300/300 bps) connections due to serious degradation of throughput at low speeds.

Also, it is recommended that when data compression is enabled, speed buffering is employed with the terminal speed set to at least twice the modem line speed for MNP5 and four times for V.42bis. Some form of flow control should also be enabled between terminal and modem.

To obtain maximum benefit from your modem's data compression abilities for high speed (V.34, V.FC, V.32 and V.32bis) connections, a terminal speed greater than 19200 bps may be desirable. However, some computers operate unreliably at terminal (DTE) speeds above 19200 bps, mainly due to the type of UART fitted in their serial port. For optimum performance, a high speed UART of type 16550 is required.

Both MNP and V.42 operate transparently so that if only one side of the connection can operate in error correction mode, both sides operate without error correction. This transparency is achieved by a process of negotiation between the two modems. Any negotiation takes place shortly after the two modems connect, allowing both systems to identify each others capabilities and decide if error correction is possible.

V.42bis uses a string encoding algorithm called BTLZ, in which frequently occurring strings of characters are replaced by code words. The "dictionary" of strings is dynamically maintained during transmission and keeps track of changes in the data; new strings are added and old strings are deleted. As the data may not always be compressible (for example encrypted or pre-compressed data) the modem has the ability to switch between compressed and uncompressed modes of operation. Compression performance is continually monitored and, if no compression is obtained, the modem transmits the data in uncompressed form. Even while in uncompressed mode, the modem monitors the characteristics of the data and switches compression back on as soon as some benefit can be achieved.

V.42bis always produces some performance improvement unlike MNP5, which produces a throughput reduction on previously compressed data. This explains why V.42bis is preferred over MNP5 and why it is the modem default compression technique.

Class 2: Data can be transferred in both directions simultaneously. Up to 8 consecutive data blocks may be transmitted and left unacknowledged by the remote modem at any one time. This improves data flow and hence throughput.

Class 3: Data can be transferred from modem to modem synchronously (sent as a single block), giving a 20% increase in throughput due to the absence of the start and stop bits found in asynchronous data (alternately sent and received in small blocks).

Class 4: Data phase optimisation increases the efficiency of data transfer by reducing the number of bytes used by the header and tail of the packet thus optimising the total number of bytes per data packet. It allows up to 256 byte data blocks to be transferred.

Class 5: Data compression, using a technique called run length encoding allows data to be transferred at around twice the normal rate.

Class 10: Data throughput optimisation over poor quality lines. As the line condition varies, MNP10 dynamically alters the data packet size to promote optimum throughput. A minimum of an MNP4 connection is required before up-shift to MNP10 can occur.

When two MNP modems negotiate, they inform each other of their capabilities and only use the classes that are common to both modems. So if an MNP 5 modem connects to an MNP 3 modem, both sides use the features of MNP 2 and 3 only.

Some non-error correcting remote modems interpret error correction negotiations as data. This is seen as "garbage" at the remote DTE as first V.42 and then MNP error correction negotiation is attempted. This may cause a problem in certain applications. If it is known that the remote modem is a non-error correcting modem, use the \N0 command to prevent your modem from attempting error correction negotiation.

If MNP negotiation is unsuccessful the modem disconnects and issues the NO CARRIER message. Should you wish to make a connection to a remote modem which offers both MNP4 and V.42 LAPM error correction but only MNP5 data compression, it may be necessary to enforce the MNP error correction at the modem by issuing the \N5 command. This allows negotiation for MNP error correction, to ensure MNP5 data compression is achieved.

The W1 command selects two additional messages and modifies the connect message. When a connection is established, messages of the following form are output:

CARRIER 9600
PROTOCOL: LAPM (or MNP or MNP 10 or NONE)
CONNECT 9600

The carrier message gives the current line speed; protocol shows what type of error correction is in use; and the connect message gives the DTE speed rather than the line speed.

W0 is similar to the default of W2 except that the speed information attached to the connect message refers to the DTE speed rather than the line speed. Further control over the actual messages output during connection may be obtained by use of register S95. For example: ATS95=0 <Return> disables a feature which appends /ARQ to the connect message for any error corrected connections. See the S registers chapter for more information on customising the connect message format.