The 1993 Kermit News article, whose purpose was to dispel widespread myths and misconceptions about Kermit, is reproduced in its original form below. Bear in mind that a lot has happened since 1993. Kermit protocol and software have kept pace with technology. Kermit is not just a modem program any more. In fact, it hasn't been just a modem program since 1988. Now it's also a Telnet client, an SSH client, an Internet service, an FTP client, an HTTP client, and much more, all fully scriptable with Kermit's own built-in portable script programming language. Visit the Kermit Project website for an update. Also see: a 1990 analysis of Kermit protocol performance and a more up-to-date discussion the performance and role of Kermit protocol in the modern world.In the early 1980s, the first generation of Kermit software used the basic Kermit protocol: stop-and-wait exchange of short packets. The basic protocol is easily implemented and highly robust, and led to its rapid proliferation to hundreds of hardware and software platforms where it proved a success in transferring files under even the most difficult conditions.
The new generation of Kermit software improves on the original robust qualities and dramatically boosts performance without sacrificing compatibility with the earlier generation. Protocol capabilities are negotiated automatically so the newest, most advanced versions can still exchange files with the earliest or most minimal versions.
Kermit's performance features include long packets, sliding windows, control-prefixing selection, locking shifts, and compression. The first three have the potential for causing problems, and are not used unless you ask for them. This article describes Kermit's performance features and tests them against other popular protocols. The results might surprise you.
Longer packets reduce the ratio of protocol overhead to actual data, increasing the potential file transfer efficiency (the ratio of file characters transferred per second to the actual connection speed) from 86% (for 94-byte packets) to 95% (with 2500-byte packets). When conditions deteriorate on the connection, the packet length is automatically adjusted.
Original, basic Kermit was a stop-and-wait protocol because it had to work on half-duplex as well as full-duplex connections. But connections through satellites or packet-switched networks can have delays that seriously impede the efficiency of a stop-and-wait packet protocol. For example, suppose packets are 90 bytes = 900 bits long, and there is a one-second transmission delay. For one packet and its response, the round-trip delay is 2 seconds. At 300 bits per second (bps), the 3 seconds required to transmit the packet plus the 2-second delay make 5 seconds, so throughput is 180 bps, 60% efficiency. At 9600 bps, it takes only 1/10 second to transmit the same packet, but the delay is still 2 seconds. Throughput is only 428 bps, 4.5% efficiency. When connections have delays, efficiency can be improved by lengthening the packets, but only if the connection is clean. On a noisy connection, longer packets are more likely to be damaged in transmission and take longer to retransmit.
On full-duplex connections, the new generation of Kermit software (IBM mainframe Kermit excluded, which always has a half-duplex connection) can transmit packets in a steady stream, processing the acknowledgements later as they arrive, thus eliminating the effects of transmission delays, and also eliminating the overhead of the acknowledgements themselves, since they are "on the wire" at the same time as the data packets and therefore don't take up any extra transmission time. This technique is called sliding windows, because multiple packets are kept in a buffer (window) that "slides" forward whenever the oldest packet in the window is acknowledged.
Using 94-byte packets without sliding windows on a connection that has a 1-second delay results (according to actual measurements) in an efficiency of about 8%. Raising the packet length to 1500 on the same connection increases the efficiency to 63%. Using sliding windows on the same connection raises the efficiency to 82-90%, depending on the packet length.
To see a dramatic speed improvement using MS-DOS Kermit 3.13 and/or C-Kermit 5A, simply give these commands to each Kermit before file transfer:
SET WINDOW 3 SET RECEIVE PACKET-LENGTH 1000Adjust as necessary. Longer delays require larger windows; noisier connections (or devices with small input buffers) need shorter packets. MS-DOS Kermit 3.13 and most versions of C-Kermit 5A allow the theoretical maximum sizes, 31 and 9024 respectively, sufficient to overcome any reasonable delay (for example, between the earth and the moon).
Analysis of large volumes of both textual and binary data shows an average compression of 15-20%. Dramatic savings are achieved in certain types of files, including tabular text (or any other type of text with lots of repeated characters) and executable programs containing large amounts of pre-zeroed data.
On some connections it is safe to transmit certain control characters "bare," without prefixing or encoding. "Unprefixing" of control characters can speed up the transfer of binary files, particularly precompressed files, which tend to contain a lot of bytes in the control range. MS-DOS Kermit 3.13 and C-Kermit 5A(189) give you the ability to specify which control characters are to be prefixed and which are not. In the benchmarks on pages 7 and 8, only three control characters are prefixed:
SET CONTROL UNPREFIXED ALL SET CONTROL PREFIXED 0 1 129This technique can be used even if the Kermit program on the other end doesn't know anything about it, since well-designed Kermit software will, indeed, accept bare control characters literally. The three exceptions above are NUL (0), which is used internally by C-Kermit for string termination, and SOH (1) and SOH+parity (129), Kermit's normal packet-start indicator. It takes some experimentation to find the maximum safe set. That's why Kermit prefixes all control characters by default: first make it work, then make it fast.
On 8-bit connections, Kermit transfers 8-bit data with no additional overhead. On 7-bit connections, which are quite common--these are the connections that use even, odd, mark, or space parity, often without the user's knowledge--8-bit data is encoded using a single-shift technique, a prefix character for each byte whose 8th bit is 1, similar to holding down the Shift key on your keyboard for each 8-bit character. This allows Kermit to work where most other protocols fail. The amount of prefixing ranges from 0% up to 100%, depending on the type of file.
Locking shifts are supported by MS-DOS Kermit 3.13, C-Kermit 5A, and IBM Mainframe Kermit 4.2.4, and are negotiated automatically when parity is in use (including when parity is detected automatically). They reduce the 8th-bit prefixing penalty anywhere from 0% to 100%, depending on the groupings of the 8-bit characters within the file.
Table 1: Kermit Implementations ComparedThe results speak for themselves.
Window Packet Time Speed PC Software Size Length secs cps Effic. Remarks
Telix 1 94 131 1052 55% Long packets and s/w not avail MTEZ 1 94 119 1158 60% Long packets and s/w not avail Smartcom III 1 94 113 1220 64% Long packets and s/w not avail PROCOMM PLUS 14 1000 77 1790 93% Window size not selectable Zstem 340 2 1000 74 1863 97% Maximum window size 2 MS-DOS Kermit 3 1000 72 1915 99% Full control-character prefixing MS-DOS Kermit 3 1000 69 1999 104% Only 0, 1, and 129 prefixed
If you thought Kermit file transfer was slow, you were probably not using real Kermit software!The UNIX-resident copy of the file, like all UNIX text files, uses only linefeed (LF) for line termination. During text-mode transfer, each LF becomes carriage return and linefeed (CRLF). There are 2814 lines in the file, so the actual data size during (and after) transfer is 137901. Since the connection runs at 1920 characters per second (10 bits per character), a 100%-efficiency transfer should take 137901 / 1920 = 71.8 seconds. The following PC communications software was used:
MS-DOS Kermit 3.13 Columbia University, New York, NY, USA MTEZ 1.16 MagicSoft, Inc., Lombard, IL, USA PROCOMM PLUS 2.0 Datastorm Technologies, Inc., Columbia, MO, USA Smartcom III 1.0A Hayes Microcomputer Products, Inc, Norcross, GA, US Telix 3.21 deltaComm Development, Cary, NC, USA Zstem 340 1.0.4 KEA Systems Ltd., Burnaby, BC, Canada
ASCII Text: IKCKER.DOC 137901 bytes Our original ASCII text file UNIX Binary: uuencode 24576 bytes A Sun SPARC binary executable program PC Binary: KERMIT.EXE 197928 bytes An MS-DOS binary executable program Precompressed: KERMIT.ZIP 238584 bytes A compressed ZIP archiveTests were performed on four types of connections and in each trial, Kermit transfers used a window size of 5 and a packet length of 5000, and control prefixing was disabled except for NUL (0), Ctrl-A (1), and 129. As the tables show, Kermit outperforms the competition every time.
Table 2 shows the figures for transferring all four files with each of the four protocols on same direct connection used for Table 1. In this and the following tables, the secs column shows the elapsed time of transfer in seconds, the cps column shows actual file characters transferred per second, and the eff column shows the percent efficiency (file characters per second divided by the connection speed).
Table 2: X- Y- and ZMODEM vs Kermit on a 19200-bps Direct Connection
XMODEM YMODEM ZMODEM KERMIT File Type secs cps eff secs cps eff secs cps eff secs cps eff
ASCII Text 89 1549 81% 76 1814 95% 73 1889 98% 69 1999 104% UNIX Binary 15 1638 85% 13 1890 98% 13 1890 98% 9 2648 138% PC Binary 127 1558 81% 109 1816 95% 107 1850 96% 100 1979 103% Precompressed 153 1559 81% 133 1794 93% 130 1835 96% 129 1849 96%
Table 3 shows the results for a local-call dialup connection using Telebit T3000 modems, V.32bis modulation (14400 bps), V.42 error correction, V.42bis compression, RTS/CTS hardware flow control, and an interface speed of 57600 bps. The efficiencies in this table are based on the modem's 14400-bps connection speed, and therefore also reflect the modem's compression methods.
Table 3: X- Y- and ZMODEM vs Kermit with High-Speed Modems
XMODEM YMODEM ZMODEM KERMIT File Type secs cps eff secs cps eff secs cps eff secs cps eff
ASCII Text 221 624 43% 79 1746 121% 42 3283 228% 39 3535 246% UNIX Binary 32 768 53% 13 1890 131% 15 1638 114% 3 8192 569% PC Binary 346 572 40% 129 1534 106% 83 2385 166% 80 2474 172% Precompressed 500 477 33% 208 1147 79% 149 1601 111% 148 1612 112%
So far we've looked only at connections with no delays. Table 4 (also see cover, left group) shows the results for a V.32 9600-bps cross-country dialup connection from the same PC to a PC/486-50 running UNIX System V R4, with the same C-Kermit, sx, sb, and sz software as on the Sun. The round-trip delay is a fraction of a second. No error correction or compression is done by the modems, but the connection is clean and no errors occurred.
Table 4: X- Y- and ZMODEM vs Kermit with Delays at 9600 bps
XMODEM YMODEM ZMODEM KERMIT File Type secs cps eff secs cps eff secs cps eff secs cps eff
ASCII Text 422 327 33% 253 545 57% 217 635 66% 151 913 95% UNIX Binary 73 337 35% 41 599 62% 32 768 80% 8 3072 320% PC Binary 536 369 38% 319 620 65% 271 730 76% 207 956 99% Precompressed 710 336 37% 363 657 68% 314 759 79% 284 840 87%
But if we always had clean connections, why would we need error-correcting file-transfer protocols? Table 5 (and middle group, cover) shows the results for the same cross-country connection, same settings, but with short bursts of noise injected every two seconds, which cause errors and retransmissions in all four protocols.
Table 5: X- Y- and ZMODEM vs Kermit with Delays and Noise at 9600 bps
XMODEM YMODEM ZMODEM KERMIT File Type secs cps eff secs cps eff secs cps eff secs cps eff
ASCII Text 3346 41 4% fail 0 0% 438 315 33% 206 669 70% UNIX Binary 573 43 4% 58 424 44% 144 171 18% 9 2736 284% PC Binary 5154 42 4% fail 0 0% 566 350 36% 281 706 74% Precompressed 5917 40 4% fail 0 0% 694 344 36% 385 621 65%
Table 6: File Transfer on a 7-Bit Connection
XMODEM YMODEM ZMODEM KERMIT File Type secs cps eff secs cps eff secs cps eff secs cps eff
ASCII Text - 0 0% - 0 0% - 0 0% 81 1702 88% UNIX Binary - 0 0% - 0 0% - 0 0% 9 2730 142% PC Binary - 0 0% - 0 0% - 0 0% 162 1221 63% Precompressed - 0 0% - 0 0% - 0 0% 243 981 51%
The table shows Kermit file transfer to be infinitely more efficient than X-Y-Z-MODEM transfer with IBM mainframes, because X-Y-Z-MODEM implementations do not work with IBM mainframe operating systems such as VM/CMS, MVS/TSO, or CICS, whereas Kermit works with all of them. Of course, 7-bit connections are not peculiar to IBM mainframes. They are also used by other types of mainframes and front ends as well as many types of networks and devices, including some X.25-based public data networks and certain terminal servers. You can use Kermit to transfer files on these connections, but not X-Y-Z-MODEM protocols.
Table 7 shows the results of attempting to upload typical Russian and Japanese 8-bit text files over a 19200-bps 7-bit serial connection to an IBM mainframe using X-Y-Z-MODEM (it can't be done), Kermit with only single shifts (SS), and Kermit with locking shifts (LS). The Kermit window size is 1 and the packet length is 1920. In these cases, locking shifts improve the speed of transfer 30-40%.
Table 7: Effect of Locking Shifts
X-Y-Z-MODEM KERMIT (SS) KERMIT (LS) File Type Size secs cps eff secs cps eff secs cps eff
Russian Text 52046 - 0 0% 55 946 49% 39 1334 69% Japanese Text 29706 - 0 0% 34 873 45% 20 1485 77%