caf@omen.UUCP (Chuck Forsberg WA7KGX) (01/20/86)
To answer some questions in INFO-KERMIT, I ran some tests transferring files with a variety of protocols, including SuperKermit (Kermit with Sliding Windows). Here are the results. SuperKermit: Some File Transmission Time Comparisons Chuck Forsberg 1-20-86 Two files were used for this series of tests. A 112070 byte .EXE file produced by the Xenix to DOS cross development system was used to test the transfer of binary files. Of the 19886 nulls in the file, many were in buffers, giving a chance to test Kermit's run length compression. A 11456 byte document produced by nroff contained no special characters save CR and LF. The document used little or no indentation. Transmissions were from a 9 mHz PC-AT running DOS 3.1 or SCO SYS V Xenix, to a PC with a NEC V20 at the standard 4.77 mHz. Ramdisks were used on the DOS machines. The 9600 bps transfers used a direct connection between the adjacent machines. 1200 bps transfers used a Hayes 1200 and MI-2 212a modem dialup. Software used was Professional-YAM 15.24, Crosstalk 3.6, and Unix sb(1). Pro-YAM to Pro-YAM SuperKermit transfers used 3 byte block check (CRC-16), eight bit transfers (no quoting), and compression. Transfers with The Source used the Portland OR Uninet node. Source Kermit transfers used 1 byte block check, eight bit transfer, and no compression. Previous tests have indicated Telenet gives similar results on downloads from The Source but was very much slower on uploads thanks to poor network buffering. .EXE File (112070 bytes) Time Speed Conditions 2:00 9600 Xenix to Pro-YAM YMODEM-g 2:00 9600 Pro-YAM to Pro-YAM YMODEM-g 2:11 9600 Pro-YAM to Pro-YAM XMODEM/CRC 3:54 9600 Pro-YAM to Pro-YAM SuperKermit 4:10 9600 Xenix to Crosstalk XMODEM 5:20 9600 Pro-YAM to Pro-YAM Kermit (NO Windowing) 15:55 1200 Pro-YAM to Pro-YAM YMODEM-k 22:33 1200 Pro-YAM to Pro-YAM SuperKermit 25:22 1200 Pro-YAM to The Source SuperKermit 25:95 1200 The Source to Pro-YAM SuperKermit Nroff output file (11456 bytes) (all at 1200 bps) Time Conditions 1:49 Pro-YAM to Pro-YAM YMODEM-k 1:53 Pro-YAM to Pro-YAM SuperKermit 1:59 Pro-YAM to The Source SuperKermit 5:32 Pro-YAM to The Source Kermit (NO Windowing) ****** DISCUSSION ****** Between two directly connected microcomputers, XMODEM protocol gives good results, 855 bytes per second throughout out of 9600 bps. The 1024 byte blocks used by Pro-YAM's YMODEM-k and YMODEM-g give a throughput of 933 bytes per second (97 per cent efficiency). Pro-YAM's Kermit/SuperKermit routines are based on the code developed at The Source, which in turn is based on C-Kermit. Compared to the earlier Unix Kermit, C-Kermit uses extra layers of processing which limit performance at high speeds. The .EXE file should transfer in 2:49 but in fact takes 3:54. Most of this delay was enforced by the PC stopping the transfer with XOFF flow control. A PC-AT or AT&T 6300 should be able to receive data with SuperKermit at 9600 bps with little or no flow control. SuperKermit does allow the receiver (in this case the slower PC) to overlap serial transfers with its processing. Without SuperKermit, all the processing must be done sequentially, resulting in a 5:20 transfer time for the same file. The advantage of Sliding Windows or other means of sending multiple blocks can be seen by comparing the timing for the Xenix to Crosstalk XMODEM download (4:10) with YMODEM-g download (2:00). When national or global packet switched networks introduce delays, the difference becomes significant even at 1200 bps. The 1:52 transmission time between two SuperKermits only loses six seconds when uploading to The Source. Regular Kermit (no windowing) takes more than twice as long at 5:32. Standard XMODEM transfers with Compuserve suffer from similar delays. The size of the sliding window has little effect on performance as long as it is large enough to contain the outstanding packets. The maximum possible is 31, but it appears that 8 are sufficient for normal conditions. Of course, if the timesharing system or the network restricts the flow of data, no amount of windowing is going to help. I did notice a slight amount of network flow control when uploading files to The Source. In the non window transfer with The Source, round trip delay time was about 1.6 seconds according to my calculations (it seemed longer). YMODEM-k under these conditions would have uploaded the .EXE file in 19 minutes compared to SuperKermit's 25 minutes. A Kermit transfer with 1024 byte packets without windowing would have taken 27 minutes (losing 3 minutes from the delays, gaining a minute from decreased overhead). The benefits derived from Kermit's run length encoding form of compression are greatly dependent on the nature of the files being transmitted. It appears most of the difference between the 22:33 minute Pro-YAM to Pro-YAM SuperKermit transfer and the 25:22 Pro-YAM to The Source transfer is related to compression available in the Pro-YAM Kermit but not The Source. However, long files downloaded from bulletin boards are often SQueezed or compressed before transmission, reducing the value of Kermit's compression. Most compression programs emit all 8 bit codes, resulting in an average 25 per cent Kermit efficiency loss from control character quoting. The main Kermit inefficiency in transferring binary files is control character quoting, which increases transmission time by 25 per cent average. A useful Kermit extension would be a way to allow most control characters to be transmitted without quoting. A lesser source of overhead comes from the characters that frame Kermit packets. It is unfortunate that Kermit does not provide for longer packets. SuperKermit: Unfinished Business The main item of unfinished business in SuperKermit is to determine the best criteria with which to force a windowing transfer to abort in a timely fashion without compromising the robustness of the protocol. A window size of 31 means up to 3100 bytes can be sent to the wrong program if one end of a SuperKermit transfer exits prematurely. A series of noise bursts such as dialing crosstalk can generate dozens of spurious packets. The normal method of stopping until the line quiets cannot be applied when the window is open. Would somebody with ARPANET access please forward this to Info-Kermit digest. -- Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf CIS:70715,131 Author of Professional-YAM communications Tools for PCDOS and Unix Omen Technology Inc 17505-V NW Sauvie Island Road Portland OR 97231 Voice: 503-621-3406 TeleGodzilla: 621-3746 300/1200 L.sys entry for omen: omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp