Xmodem Versus Kermit

There have been several communication-protocol articles
published in microcomputer magazines in recent months that have
compared the benefits of Microcom's MNP and Tymnet's X.PC line-
oriented protocols. These articles have almost completely ignored
the two most popular file transfer protocols--Xmodem and Kermit.
Because of their popularity and utility, the Xmodem and Kermit
protocols deserve equal coverage. This article provides that
coverage plus a comparison of all four protocols.

Xmodem

The Xmodem file transfer protocol, originally referred to as
the MODEM protocol, was designed by Ward Christensen in 1979 to
facilitate error-checked file transfers between microcomputers
operating under the CP/M operating system. The protocol was
designed over a weekend and subsequently implemented by Mr.
Christensen and friends in the Chicago area. The MODEM protocol
was intended as a simple and easily implemented technique of
ensuring near error-free transfers of text and binary files. The
protocol was never intended as a solution to all communication
problems and its weaknesses are just beginning to surface. The
enhanced MODEM protocols--MODEM7, Xmodem, XmodemCRC, and Batch
Xmodem--have extended the life of Ward's original design, but they
share common weaknesses.

Because of the widespread use of the Xmodem version of the
MODEM protocol, this will the version discussed in detail. There
will also refererence to other MODEM versions, but we will leave
the detailed review of these variations to others.

Xmodem is an excellent protocol for low-speed file transfers
between personal computers located within local dialing distances
of each other. As you can see from Figures 1, 2, and 3, Xmodem
has a single character error-check response and a 128-byte data
packet size. These translate into low overhead and efficient file
transfers as long as telephone connections are of high quality and
the computers at both ends of the link can operate under Xmodem's
stringent communication parameter requirements. Most
microcomputers operated in hobbyist environments met these
requirements in the past, but things are changing.


Xmodem Kermit X.PC MNP
------ ------ ----- -----
Types of File Transfer
Single File yes yes Appl yes
Multiple Files (Wildcard) no yes Appl yes
Text yes yes yes yes
Data yes yes yes yes
Binary yes yes yes yes

Required Data Bits 8 7 or 8 8 8

Error Checking
6-Bit Checksum no yes no no
8-Bit Checksum yes no no no
12-Bit Checksum no yes no no
CCITT CRC-16 no yes yes yes

2
Error Checking Response
Single Character yes no no no
Error Checked Packet no yes yes yes

Data Packet Size (bytes) 128 0-94 16-256 1-256

Data Compression no yes no no

File Attribute Transfer
File Size no yes Appl yes
Time/Date Stamp no yes Appl yes

Sliding Window Support
Single Packet yes yes no no
Multiple Packets no 1-32 2-15 yes

Negotiated Parameters
Packet Size no yes yes yes
Packets in Window no yes yes yes
Error-check type no yes no no
Data Compression no yes no no

Xon/Xoff Flow Control no yes yes no

Multiple Virtual Circuits no no 1-15 no


Note: Appl - Not defined in protocol specification and depends
upon application implementation

Figure 1. Asynchronous communication protocol features.
---------------------------------------------------------------


Receiving Transmitting
Computer Computer

| |
| +------+-------+-------------+------+-------+ |
|<---| SOH | Pkt # | Pkt # Compl | Data | Check |---|
| +------+-------+-------------+------+-------+ |
| |
| |
| +-------------------+ |
|----------------| ACK/NAK character |-------------->|
| +-------------------+ |
V V


Legend: SOH - Start of packet header indicator
Pkt # - Sequential packet number
Pkt # compl - Packet number complement
Data - 128 bytes of 8-bit data
Checksum - 8-bit error-check character
ACK/NAK - Single acknowledge or negative
acknowledge character

Figure 2. Xmodem data packet and ACK/NAK response.


3
------------------------------------------------------------


Receiving Transmitting
Computer Computer
Ready to Ready to
Receive Transmit
| |
| |
|-----------------\NAK character\--------------->|
| |
|<--------/File data packet # 1/Checksum/--------|
| |
|-----------------\ACK character\--------------->|
| |
|<--------/File data packet # 2/Checksum/--------|
| |
|-----------------\ACK character\--------------->|
. .
. .
. .
|<---------/Last file data packet/Checksum/------|
| |
|-----------------\ACK character\--------------->|
| |
|<----------------/EOT character/----------------|
| |
|-----------------\ACK character\--------------->|
| |
V V

File File
Receipt Transmit
Ends Ends

Figure 3. Xmodem protocol file transfer.

----------------------------------------------------------------

4

Xmodem has been a workhorse for microcomputers for several
years. Andrew Fluegelman gave the protocol its greatest boost
with IBM PCs by including it in the ubiquitous PC-TALK.III. Larry
Jordan debugged the Xmodem that he originally discovered in
the RBBS bulletin board system and made it available on large
scale through the Capital PC public domain library. Rich
Schinnell also helped promote Xmodem by incorporating it into
his HOSTCOMM software modules. The Capital PC Monitor and PC
World have also helped promote Xmodem as a minimum standard
protocol for personal computers by publishing articles on the
subject. Through these efforts and others, Xmodem has become
widely used to transfer text and data files. We should not,
however, let Xmodem's past utility blind us of its future
potential. Technology may soon make this wonderful capability
obsolete.

When Xmodem was written, the predominant hobbyist modem speed
was 300 bits per second (bps) and most hobbyist communications
were conducted through equipment provided by AT&T.


The cost of modems has decreased remarkably since 1979, and
the typical personal computer communication equipment now includes
a 1200-bps modem. As modem prices continue to fall, faster modems
(2400 bps and higher) will reach the personal computer owner's
budget level. One of the prices you pay for these faster modems,
however, is a higher communications error rate. Xmodem was
designed for low error rates and often fails at communication
speeds of 2400 bps and higher.

The second change in communications that adversely affects
Xmodem's performance was the arrival of low-cost alternatives to
AT&T's communication services. Unfortunately, a hidden price you
pay with many of these services is a higher communication noise
level and data communications error rate. The higher noise levels
may only be annoying when you use these low-cost alternatives for
voice communication, but they can be devastating for Xmodem file
transfers.

The high communication error rates that occur at high
asynchronous communication speeds and on low quality telephone
lines are tough for Xmodem to handle for two reasons. First, the
line noise often causes a series of data bit errors. Xmodem uses a
simple checksum that is the sum of the ASCII values of all 128
data bytes, modulo 255. Simply translated, this means that
multiple bit changes in a data packet caused by line noise can
result in the same checksum as the original data. Thus, a packet
error can occur without Xmodem detecting it and requesting a
retransmission of the data. Second, line noise can alter the
single character packet transmission response. Xmodem can properly
send a packet, but the receiver's acknowledgement character can be
altered to indicate receipt of bad data; this will result in the
unnecessary retransmission of data packets. The receiver's
response can also be accidentally altered by line noise to
indicate abnormal termination of transfer. An ACK or NAK character
can become a Control-X character and terminate the file transfer
after 90 percent of a huge file has been received--a time
consuming and frustrating experience.

5
There have been many enhancements added to Xmodem during the
past 3 years, but none of the changes overcome two major flaws in
its design--the single character ACK/NAK response to packet
transfers and the 8-data-bit communication requirement. By not
providing a packet and a packet number for all data transmissions,
enhancements such as sliding windows cannot be added to Xmodem.
The 8 data bit requirement precludes its use with some public data
networks and large computers.

Public data networks (PDNs) such as Tymnet, Telenet, and
Uninet sometimes create time delays during data communications
that can cause problems with file transfer protocols. These
communication services convert all data into packets and route the
packets through ground and satellite equipment. The packet
construction and routing can produce as much as a three second
delay in the receipt of an acknowledge or negative acknowledge to
a file transfer protocol data packet transmission. For a 48K file
this could add 19 minutes to a normal 6 minute file transfer when
communicating at 1200 bps--a 300 percent increase in file transfer
time!

Some file transfer protocols such as BLAST and Kermit get
around the PDN time delay problem by providing a sliding window of
packets. The protocol can send data packets continuously unless a
fixed maximum number of transmitted packets have not been
acknowledged as properly received. This technique requires a
full-duplex communication link because data packets are sent out
simultaneous with the receipt of ACK/NAK responses from the
receiving computer. This technique also requires that the
receiver's ACK/NAK response contain the packet number associated
with the response. The sending computer must be able to determine
which previously transmitted packets it has to retransmit because
of errors detected by the receiving computer.

Xmodem does not provide data packet numbers with its ACK/NAK
responses to received data. Without this feature, Xmodem is
destined to live in a half-duplex world where only one packet of
data at a time can be transmitted. The next packet can only be
sent after the receiver responds to the last packet sent. Time
delay caused by this half-duplex mode can be expensive and can
cause protocol timeout problems that result in aborted file
transfers.

Another characteristic of some PDNs that precludes the use of
Xmodem is the communication parity bit. Some PDNs assume this
data bit is not used and convert it into a zero or one for PDN
purposes. Xmodem requires no parity and a full 8 data bits for
transmission of binary data, extended ASCII characters, and its
own internally generated error-checking checksum. Because of
Xmodem's 8 data bit requirement, it cannot be used with 7-bit PDNs
such as Telenet.

6
Xmodem's 8-data-bit requirement and its 128-byte data packet
size, ideal parameters for PC-to-PC communications, also preclude
its use with many mainframe computers. The front-end communica-
tion processors or TTY communication ports on some large computers
such as Prime can only be configured for 7 data bits. Xmodem is
incompatible with these machines. Other large computers such as
Honeywell have small communication buffers and cannot accommodate
the receipt of a 128-byte Xmodem packet without losing characters.

There are other problems with Xmodem in a multivendor
computer environment. To cover all these problems would require
more space than allowed in this article. During the following
discussion of the Kermit file transfer protocol you will see some
of these problem areas.



Kermit

The Kermit file transfer protocol was designed by Frank da Cruz
and Bill Catchings at Columbia University in 1981. The university
had a variety of computers, including IBM mainframes, DEC
minicomputers, and microcomputers, but University personnel could
not easily move files from one type of machine to another.
Improper translations of characters sometimes occurred with text
files, and binary files either caused problems with the
communication equipment or could not be transferred because of
communication equipment limitations. Necessity became the mother
of invention.

Frank da Cruz and Bill Catchings set out to design and
implement a file transfer protocol that would allow any type of
computer to properly receive a file sent by another type of
computer. The protocol they devised became known as Kermit, a
name taken from Jim Henson's famous green frog. The protocol
design was based on the recommendations of the International
Standards Organization in accordance with the Open System
Interface model. The protocol is similar in many ways to the
Xmodem protocol. The differences between Kermit and Xmodem,
however, give Kermit more growth potential and allow more flexible
implementations.

Kermit is an excellent protocol to use for file transfers
between dissimilar computers, for high-speed file transfers, for
file transfers over long distances, and for the transfer of file
groups. As you can see from Figures 1 and 4, Kermit has many
optional features in addition to full packets with error checking
for both data and ACK/NAK response data. Unfortunately, Kermit's
features and flexibility add overhead to the protocol that may be
undesirable under some circumstances. For direct-dial, low-speed
communications (under 2400 bps) between microcomputers made by the
same vendor, Kermit's power is wasted. A protocol such as Xmodem
can be 10 to 40 percent more efficient under these circumstances.

7
------------------------------------

Receiving Transmitting
Computer Computer

| |
| +------+------------+-------+----------+------+-------+ |
|<---| Mark | Pkt length | Pkt # | Pkt type | Data | Check |---|
| +------+------------+-------+----------+------+-------+ |
| |
| |
| +-------+------+---------+-------+------------+------+ |
|----| Check | Data | ACK/NAK | Pkt # | Pkt length | Mark |--->|
| +-------+------+---------+-------+------------+------+ |
V V

Legend: Mark - Mark start of packet
Pkt length - Number of characters that follow this field
Pkt # - Packet sequence number
Pkt type - Packet type (Data, Acknowledge, Negative
acknowledge, Send-initiate, Break transmission,
File header, End of file, or Error)
Data - 7 or 8 bit data (if required)
Check - Error check byte(s)
ACK/NAK - Special acknowledge or negative acknowledge
character followed by data if required

Note: Packet fields are shown in order of arrival starting at the
arrow that indicates flow direction.

Figure 4. Kermit data and ACK/NAK packets.


------------------------------------------------------------


Kermit's power is unleashed, however, in typical business,
government and educational institution communications. One of the
capabilities that gives Kermit its power is the feature
negotiation it performs each time a file is transferred. This
"binding" process is accomplished by the exchange of send-initiate
packets between the two communicating computers. As shown in
Figure 5, the sending computer transmits its send-initiate packet
to the receiving computer. The receiver acknowledges proper
receipt of the packet and sends its own send-initiate packet along
with the acknowledgement. The two computers then compare these
packets and select, for this file or file group transfer only, the
features that both computers can support. This send-initiate
packet exchange allows any Kermit implementation to communicate
with any other Kermit implementation. The transfer-by-transfer
renegotiation also allows the computer operator on either end of
the link to alter parameters such as packet size and error-
checking technique to optimize communication throughput based on
the specific circumstances at hand.

8
----------------------------------

Receiving Transmitting
Computer Computer
Ready to Ready to
Receive Transmit
| |
|<----------/Send-initiate packet/Check/---------|
| |
|-----------\Check\Send-initiate packet\-------->|
| |
|<-----------/File-header packet/Check/----------|
| |
|---------------\Check\ACK packet\-------------->|
| |
|<----------/File data packet # 1/Check/---------|
| |
|---------------\Check\ACK packet\-------------->|
| |
|<----------/File data packet # 2/Check/---------|
| |
|---------------\Check\ACK packet\-------------->|
. .
. .
. .
|<-----------/Last file data packet/Check/-------|
| |
|---------------\Check\ACK packet\-------------->|
| |
|<------------/End of file packet/check/---------|
| |
|---------------\Check\ACK packet\-------------->|
. .
. Send additional files in group .
. by repeating the above steps .
. beginning with step three. .
. .
|<------/End of transmission packet/check/-------|
| |
|---------------\Check\ACK packet\-------------->|
| |
V V
File File
Receipt Transmit
Ends Ends

Figure 5. Kermit protocol file transfer.

----------------------------------------------------------------

One of the features two Kermits negotiate is the error-
checking technique to be used. Kermit supports three techniques:
a 6-bit checksum, a 12-bit checksum and a CRC-16. The comm-
unication overhead of each of these techniques increases with its
degree of error-detection capability. The 6-bit checksum adds one
byte to each packet and is calculated the same way the Xmodem
checksum is calculated. This technique is acceptable for good
quality telephone connections at speeds under 2400 bps. The 12-
bit checksum adds two bytes to each packet and is somewhat better
than the single byte Xmodem checksum. This technique is better
9
for low-quality telephone connections or high-speed
communications. The CRC-16 is based on the international CCITT
recommendations and adds three bytes to each data packet. The
CRC-16 technique is far superior to either the 6-bit or 12-bit
checksum technique and is ideal for low-quality telephone connects
or high-speed communications. The CRC-16 provides almost 100
percent error detection and is good for financial data
transactions. The price you pay for this level of integrity is
the time required to calculate the CRC-16 and the three bytes it
adds to each packet.

The flexibility in Kermit's error-detection techniques is the
ability to accommodate all three methods without changing
software. The user can select 6-bit checksum for some file
transfers and CRC-16 for others. Other protocols such as Xmodem
may provide both checksum and CRC-16, but most of these
implementations are far less flexible than Kermit's send-initiate
negotiation. To change from checksum to CRC-16 with some software
packages, you have to break the communication link, load another
version of the software and re-establish the communication link.
Not only does Kermit eliminate error-detection switch hassles, it
uses the same error detection scheme for data packets and ACK/NAK
response packets, making it far more reliable than single-
character ACK/NAK protocols such as Xmodem.

Aside from its error-detection power, Kermit provides three
features that endear it to many users. First, Kermit can
communicate through both 7-bit and 8-bit data ports regardless of
the communication hardware employed. Second, Kermit can move
groups of files without interruption. Finally, Kermit is designed
to facilitate the addition of new capabilities as communication
needs change.

Kermit can transmit both text and binary files, but it
converts all data into text during the transfer. During the
design of Kermit, its authors discovered that some control
characters (ASCII values 0-32) cannot pass through certain
communication equipment without causing undesirable results. These
characters were either modified by the communication equipment or
caused side effects such as printer initiation. Kermit's authors
also discovered that some communication equipment did not allow
the 8th data bit in a byte to be used for data--the bit either had
to be used for parity error detection or was converted to a one or
a zero. To pass compiled programs and extended ASCII characters
such as Microsoft's 8-bit graphic characters through this
equipment, the data in each byte had to be reduced from 8 bits to
7 bits.

To overcome the control character and 7-bit data limitations,
Frank da Cruz and Bill Catchings added control character
conversion and 8th-bit prefixing to their protocol. The control
character conversion is always performed by Kermit and adds to the
protocol's overhead. The 8th-bit prefixing converts all 8-bit
data bytes into two 7-bit bytes, but this is an optional feature
and only adds to the protocol's overhead when two computers cannot
communicate using a full 8 data bits.

10
Kermit's file group transfer capability saves communication
and user time. This optional wildcard feature allows the user to
transfer all files with common filename characters by executing
one command. For example, the user can enter the command SEND
*.EXE to archive on a remote host all files that are of the EXE
type. This feature allows the same send-initiate negotiation to
apply to several files, and it allows Kermit to transfer the files
without additional user input. Kermit file group transfer reduces
communication packet overhead and frees the computer user to
perform other tasks while the files are being transferred.

Kermit can agree to perform special file transfer
capabilities during its send-initiate negotiation. Two special
capabilities are file attribute transfers and sliding windows. The
file attribute capability allows Kermit to send up to 94 file
characteristics along with the file, including creation time/date
and file size. The receiving Kermit can use these attributes to
display file transfer progress or to ensure that the file's
time/date stamp is preserved. The sliding windows, a new feature
that is currently being added, allows Kermit to take advantage of
full-duplex satellite and PDN communication links to expedite file
transfers. The sliding windows along with Kermit's ability to
perform repeat character data compression can result in
substantial throughput improvements over half-duplex protocols
such as Xmodem. These Kermit capabilities as well as wildcard
file group transfers will be implemented by The SOURCE for its
clients and will be supported in the new release of PC-TALK.

Beyond features and capabilities discussed here, Kermit's
authors have added many options that allow the protocol to perform
in spite of its environment. The user is allowed to select such
items as communication flow control, timeout durations, a special
8th-bit prefixing character, a packet termination character and
others. These features have been added by Columbia University as
well as other educational and business institutions. With each
new release, Kermit comes closer to achieving its design objective
of providing one low-cost protocol that will facilitate file
transfers between any two computers.


Future Directions

Xmodem and Kermit, in spite of their capabilities to ensure
error-free file transfers, do nothing to improve the quality of
normal interactive communications with remote computers. Many
communication enthusiasts have been chagrined to discover that
logging into and writing message on a remote computer when
connected at 2400 bps is sometimes difficult. Greek and math
symbols suddenly appear on the screen or get sent to the remote
computer. These special symbols are caused by communication line
noise, and the only way to get rid of this noise with asynchronous
communication is by employing error-checking for all interactions
between the two computers.
11
Protocols such as the Microcom Networking Protocol (MNP) and
X.PC are line oriented and can provide continuous error checking
and retransmission of bad data. They also provide these services
in support of file transfers. Because of their continuous line
monitoring and sophisticated error-checking techniques, MNP and
X.PC will no doubt become major contenders in asynchronous
communication. The two handicaps these protocols suffer from are
limited availability and communication parameter constraints.
Xmodem and Kermit are already available in a number of low cost,
freeware and public domain communication packages. MNP and X.PC,
on the other hand, are new and are only available in relatively
expensive packages such as Microstuf's Crosstalk VI and
Microsoft's Access. Kermit allows binary file transfers through 7
or 8 data bit ports. MNP and X.PC require a full 8 data bit for
all file transfer.

---------------------------------

As you can see from Figure 1, each of the major asynchronous
communication protocols have strengths and weaknesses. The good
protocols will no doubt improve with time. Perhaps one of these
protocols will even become the "right protocol" for all
circumstances. Right now no single protocol meets all
communication needs. Xmodem is the least likely to succeed, based
on the evidence discussed. Someone may prove this wrong.
Probably the most general protocol will be X.PC because of its
multiple virtual circuits. X.PC is a perfect match for windowing
and multitasking capabilities--the current wave of the future for
PC-DOS. Each application or task can be simultaneously
communicating with a different remote host through the same serial
port, modem and telephone connection.

---------------------------------
12

Performance of Xmodem Versus Kermit

By Larry Jordan and Jan van der Eijk

Recently a great debate has been raging on local bulletin
boards concerning the virtues of the Xmodem and Kermit file
transfer protocols. In an attempt to settle some of this
controversy we decided to perform some data throughput tests
with both protocols.

To produce a fair comparison between these two
popular protocols, we chose several file types for transfer and
several file transfer modes so that we were able to determine
the strong points of each protocol. The features of the Xmodem
and Kermit protocols tested for this article are shown in Figure
1. The results of our tests are shown in Figure 2.


The test reults only cover point-to-point communications
between two personal computers on a dialup telephone connection.
Test results for communications through a public data network
will be developed later. The performance of the new full-duplex
sliding windows for Kermit should produce dramatic PDN results
based on the improvement it makes in point-to-point
communications. Estimates based on PDN time delays indicate the
sliding windows could at least double Kermit's throughput over
"classic Kermit" and could allow Kermit to operate at twice
Xmodem's throughput when communicating through a typical PDN
such as Tymnet or Telenet.

13

---------------------------------------------------------------
Features Xmodem Kermit
------------------------------- ------ ------
Types of File Transfer
Single File yes yes
Multiple Files (Wildcard) no yes
Text yes yes
Data yes yes
Binary yes yes

Required Data Bits 8 7 or 8

Error Checking
6-Bit Checksum no yes
8-Bit Checksum yes no
12-Bit Checksum no yes
CCITT CRC-16 no yes

Error Checking Response
Single Character yes no
Error Checked Packet no yes

Data Packet Size (bytes) 128 0-94

Data Compression no yes

File Attribute Transfer
File Size no yes
Time/Date Stamp no yes

Sliding Window Support
Single Packet yes yes
Multiple Packets no 1-32

Negotiated Parameters
Packet Size no yes
Packets in Window no yes
Error-check type no yes
Data Compression no yes

Xon/Xoff Flow Control no yes

14

Figure 1. Xmodem and Kermit Features.

---------------------------------------------------------------

Size TEST 1 TEST 2 TEST 3 TEST 4 TEST 5
in Xmodem Kermit Kermit Kermit Kermit
Filename Type bytes A,C,H,J A,C,F,G,J A,D,F,G,J A,D,F,I,J B,D,F,G,J
-------- ------ ------ ------- --------- --------- --------- ---------


BASICA.COM packed 27,520 5.33 7.35 5.55 5.72 7.58
binary

LINK.EXE packed 38,400 7.25 10.40 8.02 8.20 10.70
binary

TEST.EXE binary 36,398 6.90 8.27 6.60 6.68 8.23

FIND.EXE binary 6,528 1.38 0.47 0.38 0.40 0.40

KERMIT.TXT text 14,208 2.77 2.85 2.15 2.18 2.20

KERMIT.C source 12,870 2.48 2.17 1.70 1.77 1.70
date

Notes: 1) File transfer times are in minutes and were measured by
sending from an IBM PC AT to an IBM PC XT at 1200 bps.

2) Kermit packet size was 90 bytes.

Symbol Legend:

A - 8 data bits G - 6-bit checksum
B - 7 data bits H - 8-bit checksum
C - Half-duplex w/out sliding window I - CRC-16
D - Full-duplex w/ sliding window J - Dialup
E - Data compression OFF K - Packet switched network
F - Data compression ON


Figure 2. Xmodem and Kermit File Transfer Performance.



Point-to-Point, Half-Duplex, 8 data bits
----------------------------------------

The first tests, Tests 1 and 2, of Xmodem versus Kermit
were conducted over a dialup telephone connection at 1200 bps
using a half-duplex mode for both protocols. These tests were
performed to develop a benchmark of file transfer times. These
point-to-point tests proved to be the best cases for Xmodem when
highly packed binary files were transferred.
15

Binary files such as the PC-DOS files BASICA.COM and
LINK.EXE are highly packed binary files; they do not contain
long series of ones or zeros. Xmodem was able to move these
files 27-30 percent faster than Kermit in half-duplex mode. The
reason for this is the additional overhead Kermit has as a
percent of actual data transferred. Xmodem has a ratio of 0.97
data to total packet size. Kermit has a ratio of 0.95 data to
total packet size when a 90-byte data packet is selected.
Kermit also uses a packet to respond to data receipt, whereas
Xmodem uses a single character. Finally, the Xmodem data
packets contain 128 bytes compared to the 90-byte Kermit data
packet size used during the test--this means Kermit has to wait
for an ACK/NAK response for 42 percent more packets for the same
file size.

Kermit was able to outperform Xmodem in half-duplex mode
when small executable EXE or highly indented C source code files
were transferred. Small EXE files contain long series of binary
zeros, and C source code stored without tabs contain long series
of blanks. Kermit's repeat character data compression expedites
the transfer of these files. The FIND.EXE and KERMIT.C files
were transferred 66 and 13 percent faster respectively by
Kermit. By substituting tabs for spaces in the C source code
file and by squeezing either file with a file squeeze utility,
Kermit's data compression advantage would be eliminated. These
actions often take time at both ends of the communications link,
however, so the total time consumed could still exceed Kermit's
transfer time.


Point-to-Point, Full-Duplex, 8 data bits
----------------------------------------

The point-to-point full-duplex mode was used in Test 3 to
measure Kermit's new sliding windows capability. Xmodem always
operates in a half-duplex (stop and wait) mode regardless of the
actual duplex capability of the communications equipment. As
you can see from Figure 2, Kermit's sliding windows feature
almost eliminated its overhead disadvantage during the transfer
of large highly packed files.

By using a window size of 32 packets, packed binary files
such as BASICA.COM could be moved by Kermit 24 percent faster
than they were moved in a half-duplex mode without windows.
Lightly packed binary files (files generated by a C compiler and
linked) such as TEST. EXE were actually transferred faster by
Kermit/windows than by Xmodem. The sliding windows improved

file-transfer speeds by 19 to 25 percent over half-duplex Kermit
operation, with an average increase of 22 percent. Half-duplex
Xmodem could still move highly packed binary files 10 percent
faster than Kermit/windows. For highly indented C source code,
however, Kermit/windows could outperform Xmodem by 30 percent.
16
Kermit CRC-16
-------------
Test 4 compared Kermit's CRC-16 capability with the
standard 6-bit checksum. The CRC-16 adds two more bytes to each
packet (a 2 percent increase when 90-byte packets are used) and
takes longer to calculate than the checksum. It was found,
however, that the superior error-detection capability of the
CRC-16 did not cost much in performance. The average file-
transfer time was increased by 2 percent between Test 3 and Test
4--an indication that the only penalty is the time it takes to

transfer the two extra error-check bytes.

Using Kermit windows eliminated the impact of CRC-16
calculation time because a new packet is developed while the
last packet is sent out. The overlap reduces the CRC-16
overhead to the extra protocol bytes divided by the modem bps
transfer speed. If a slower CPU is used or a higher speed modem
is used, the penalty for CRC-16 could increase.


Point-to-Point, Full Duplex, 7 data bits
----------------------------------------

The final point-to-point test, Test 5, was conducted using
a full-duplex mode combined with a 7-data-bit communications
parameter selection. This combination allowed Kermit to perform
data compression and sliding windows but forced the conversion
of 8-bit data bytes into two 7-bit bytes. The 7-data-bit
limitation hurt file transfer performance for highly packed
binary files as expected. Text and source code files were not
affected.

Kermit's sliding windows allows the protocol to overcome
the handicap of a 7-bit data port. The results of Test 2 using
8 data bits and half-duplex mode were only slightly better than
those of Test 5 using 7 data bits and full-duplex combined with
sliding windows. Test 2 results were only 3 percent better than
Test 5 results for large, packed binary files. The difference
between the Test 2 and Test 5 results for text and source code
files shows that sliding windows allow Kermit to outperform
half-duplex 8-bit data communications even with a 7-bit
handicap.