4 Why Is Kermit So Slow Compared to Zmodem? (It Isn't!)

Path: news.columbia.edu!usenet
From: fdc@columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: [HELP] Slow Kermit Transfer ?!
Date: 19 Sep 1994 14:15:42 GMT
Organization: Columbia University
Lines: 153

In article <35jrgsINNdq2@newsman.csu.murdoch.edu.au>
anson@csuvax1.csu.murdoch.edu.au (Binh Anson) writes:
> I used Kermit 3.13 for my PC, my modem has a speed of 14.4 K, but I
> found that the downloading rate from the mainframe to my PC was
> still very slow!  I tried Telix with SZ (Z-Modem Protocol), and it
> was very fast compared to Kermit. Is there a way to accelerate
> Kermit transfer ?
>

But first, welcome to comp.protocols.kermit.misc. This is the first day of operation of this unmoderated newsgroup. I hope it will prove beneficial to all Kermit users.

To answer your question, somewhat longwindedly, since this Question is Asked so Frequently :-) ...

Zmodem is optimized for speed on the assumption that it has a clear 8-bit transparent channel with no blockages (small buffers, etc), and so, out of the box, when it works it goes fast. The tradeoff is that it often does not work at all, in which case you have to configure it in various ways -- escaping of control characters, changing window size, etc. In some cases it can't be made to work at all, either because of the nature of the connection, or because of one or both of the computers on the two ends.

Kermit, on the other hand, is configured to work -- i.e. transfer files -- out of the box, even under hostile conditions. By default, it does not assume that control characters pass through transparently, nor that large buffers are available. It does not even assume a full-duplex connection. The tradeoff is speed.

In a perfect world, there would be no tradeoffs, but the world is far from perfect. 7-bit transmission is still extremely common, small buffers are very common, even in modern terminal servers and other communications processors, flow control is rarely implemented correctly and effectively, telephone lines are still noisy, and we still have a bewildering array of communication methods needed for accessing different kinds of hosts and services. Most PCs are still shipped with non-buffered UARTs; many PCs have interrupt conflicts, noisy buses, etc; many modern modems are buggy. The list goes on. This is by way of demonstrating that Kermit's default tuning is not crazy, and goes a long way towards explaining its justified reputation for dependability.

Unfortunately, because of the tradeoffs necessary to achieve its reliability, Kermit has a reputation for slowness:

Yes, Kermit transfers are slow if you use the default tuning.

1. Ensure that you have an effective means of flow control enabled at every juncture along the communication path (this applies to any file transfer protocol). For example, when using high-speed, error-correcting modems, you should use some form of hardware flow control, most commonly RTS/CTS. You have to tell the software to use it, AND you have to tell the modem to use it too -- if the flow control methods of the PC and the modem do not agree, then data will be lost. The same is true of the modem at the other end of the connection, and the computer or device it is connected to.
2. If your modem is capable of data compression, use it. Fix the interface speed of the software to four times the connection speed if possible -- e.g. for a V.32bis 14400 bps connection, use an interface speed of 57600, or else the modem's compression capacity is likely to be wasted.
3. On network connections (e.g. TCP/IP), it is usually best to turn off flow control entirely, because the underlying networking method supplies fully effective flow control.

1. Use real Kermit software, not the many shareware and commercial packages, most of whose Kermit protocol implementations lack the performance features listed below and/or the means for the user to control them.
2. Use long packets. Kermit's default packet length is 94. You can increase it to a theoretical maximum of 9024. Give the following command to the file receiver:

         SET RECEIVE PACKET-LENGTH 2000  ; (or other length)
      

   The longer you make the packets, the more efficient the file transfer will be... IF IT WORKS. If you make packets longer than some buffer somewhere along the line, and effective flow control is lacking, the transfer might not work. Also, the longer the packet, the greater the chance it will be hit by noise, and the longer it takes to retransmit. A good starting value to try is 1000.
3. On full duplex connections, use sliding windows. Sliding windows allow packets to be transmitted in a continuous stream, rather than "stop and wait" style. The command is:

         SET WINDOW 4 ; (or other number)
      

   The maximum is 32 (or less, depending on the implementation). Give this command to both Kermit programs.

For text files and uncompressed binary files, this should give you very good performance -- efficiencies in the 85%-100% range.

For compressed files, and certain other types of binary files, you can squeeze out another 20-25% efficiency by telling Kermit not to prefix a given list of control characters. A typical sequence might be:

  SET CONTROL UNPREFIX ALL  ;  Unprefix all control characters.
  SET CONTROL PREFIX 0 1 13 129 141 ...  ; Add back prefixes for these.

This might require some trial and error because there is no way that a communication software program can know what characters are safe and which ones are not on a particular connection. For example, you might be going through an X.25 PAD where Ctrl-P will pop you back to the PAD prompt. Or you might be going through a TELNET terminal server where Ctrl-] or Ctrl-^ will pop you back to the terminal server prompt. Or the connection might be using Xon/Xoff flow control, and sending Ctrl-S as a data character might freeze the connection.

If you take all of these steps, using optimal packet lengths, window sizes, and unprefixing, you should achieve transfer rates comparable to, and often better than, the Zmodem implementations that you find in Telix, Procomm, and similar shareware and BBS packages; for example, on a V.32bis/V.42/V.42bis connection, RTS/CTS flow control, no parity, 57600 bps interface speed:

  Typical text files:        3500 cps (characters per second)
  Uncompressed binary files: 2400 cps (e.g. PC KERMIT.EXE)
  Compressed files:          1600 cps (e.g. ZIP files)

These figures come from Kermit News #5, June 1993, which is available on the Web and also via anonymous ftp from kermit.columbia.edu, directory kermit/e, file newsn5.txt (ASCII) or newsn5.ps (PostScript). Also see Kermit News #4, newsn4.txt (.ps), for a detailed discussion of long packets and sliding windows.

Kermit software is available via anonymous ftp to kermit.columbia.edu [128.59.39.2], directory kermit and its subdirectories. There are literally hundreds of different Kermit programs for *almost* every machine and operating system imaginable. The most widely used Kermit programs are:

• MS-DOS Kermit for DOS and Windows 3.x. No, this is not a native Windows application, but yes, this is the Kermit software we recommend and support for Windows 3.x. File: kermit/archives/msvibm.zip
• C-Kermit for UNIX, VMS, OS-9, AOS/VS, the Commodore Amiga, etc.
• IBM Mainframe Kermit-370 for VM/CMS, MVS/TSO, CICS, and MUSIC. kermit/b/ik*.*.

- Frank

POSTSCRIPT: The Kermit software for Windows 95 and NT is Kermit 95. It was first released in October 1995 (after this message was posted).