Kermit vs. Xmodem protocols - speed?
Frank Prindle
on the file being transmitted, exactly one byte (that byte) is sent (plus
a few bytes overhead per packet for control information). Packets are always
padded out to contain 128 bytes of file data, which is why files uploaded and
downloaded via Xmodem protocol always seem to be growing. The approximate
transfer time for a 10000 byte file via Xmodem at 1200 baud is (1.1 seconds
plus turnaround handshake time per packet) * (79 packets) = ~100 seconds.
Xmodem protocol will not work over any communication path which does not
support 8 bit raw transmission (all 8 bits of user data are transmitted without
parity, and no control characters are interpreted by the communication gear).
Ymodem is a variant of Xmodem, supporting packets containing 1024 bytes of
data instead of 128; this reduces per-packet overhead and increases transfer
speed by about 10%.
Kermit protocol is a bit more complicated. It can transmit over either 7 or
8 bit communication paths. When set to transmit over an 8 bit path, each
printable text byte is sent as is (one-to-one), but any non printable control
character is transmitted as 2 bytes; thus text files will be transmitted al-
most one-to-one, while binary files will somewhat slower. The approximate
transfer time for a 10000 byte binary file via Kermit at 1200 baud via an 8-bit
communication path is (0.8 second plus turnaround handshake time per packet) *
(160 packets) = ~160 seconds. Note that Kermit packets are variable in size
but generally shorter than Xmodem packets (typically 80 bytes of data per
packet) - thus an increase in time due to higher per-packet overhead and
turnaround handshake overhead. Over 7-bit communication paths, things get
somewhat slower, because every byte with its high order bit set must be
send as two bytes also (called eighth-bit quoting in Kermit terminology).
The previously calculated time would be more like 215 seconds over a 7-bit
path. The redeeming quality of Kermit prococol (the reason for all that
quoting of non-printing characters and sometimes of 8-bit bytes) is that is
it will transmit any file, including binary, over communication paths which
only support the printable subset of bytes plus the single control character
^A; this means it will work through LANs, over telnet ports, port selectors,
virtually any text only connection.
Certain limitations of Kermit protocol can be overcome - most implementations
of Kermit support extended packet size up to 1Kbyte to reduce the packet
overhead and turnaround handshake overhead. It is best to use Kermit with
parity set to none and eighth bit quoting disabled whenever possible. Under
the best of circumstances, a Kermit transfer will only take 1.25 times (on
average) longer than transferring the file via Xmodem (it could take even
less sometimes, because most Kermits support compression of runs of the same
byte). The C64 Kermit situation is always worse than this because the
packets are not extended in size, and the turnaround delay is quite long
(slow disk, you know!).
In summary, YES - Kermit protocol is inherently slower than Xmodem protocol.
However, it works over more diverse paths, and does not pad file length.
Frank Prindle
Pri...@NADC.navy.mil