Stuart Baker Software offers high quality consulting services and products to users of IBM PCs and compatibles (DOS and Windows)
    as well as Interdata, Perkin-Elmer and Concurrent Computer Corporation 3200 series machines (OS/32).

XMODEM and HS Modems


 

XMODEM and High Speed Modems


by Stuart Baker
Stuart Baker Software
9370 Golondrina Drive
La Mesa, CA 91941-5654
(619) 466-8811

To stay abreast of the current telecommunications technology I have experimented with the Hayes V-series Smartmodem 9600. In my last article, The Pitfalls of Progress, I stated that standard XMODEM file transfers worked very slowly with this modem. This article explores the throughput problem of XMODEM file transfer with this new breed of modem.

As I mentioned previously, these new modems must use flow control to avoid losing data. If you select XON/XOFF, you can not use transfer protocols like XMODEM. Therefore you must use RTS/CTS or no flow control at all. If you are running with BIOC on MTM, and don't plan on adding RELIANCE, use RTS/CTS. If you need both MTM/XMODEM and RELIANCE you will need to disable local flow control and take your chances with data loss. I find that totally unacceptable and hope there is a method of making RELIANCE work with RTS/CTS.

In tests of simple non-protocol throughput, I saw speeds as high as 13,000 bps. Since this exceeds the 9,600 bps speed by a considerable margin, it is obvious that the data compression used by this modem was accomplishing a lot. Seeing those high speeds, I was anxious to determine the throughput using the XMODEM protocol. The results were disappointing. The tests I performed achieved a lowly 4,600 bps throughput. Why so slow? Well for one thing, many of these new modems are not truly full duplex. They just pretend, by using a ping-pong or an asymmetrical protocol. In addition, the small 128 byte packet size does not give the data compression algorithm much to work with. What does all of this mean?

Modems that use the ping-pong approach must perform a line turn around every time you send a character in the opposite direction. This line turn around may take up to 250 milliseconds. This amounts to about 4 characters per second throughput. This is so slow that you can see the delay on a full duplex system that must echo every character. To overcome this problem, several companies adopted the asymmetrical approach. This approach uses a reverse channel, allowing a small number of characters to be transmitted in the apposite direction. This approach works much better in interactive environments but still does not perform as well as a true full duplex approach. The Hayes modem uses the ping-pong approach, but performs well in an interactive environment.

Since these modems exist, and do not perform well with common protocols like XMODEM, how do we improve their performance. It was time to experiment with packet size. Since these modems are error correcting, you should never have re-transmission problems. I first increased the standard 128 byte packet size to 1024 bytes. Throughput increased dramatically, up from 4,600 bps to greater than 10,000 bps. I next tried a 2048 byte packet, the throughput increased to just over 11,900 bps. This increase in speed is more than expected by simply reducing the number of times we turn the line around. The increase in throughput makes it obvious that the larger packet size enables the data compression to become more efficient.

Since I conducted all of these experiments with an error correcting modem, it was time to try the new packet size with a standard modem. In trying different packet sizes with non-error correction modems, I found that 2048 byte was not satisfactory. The larger the packet, the higher the chance of errors. Also, re-transmission reduces the throughput. This is because it takes a long time to re-send 2048 bytes. I have found that the 1024 byte size is useful over long distance lines using standard 2400 bps modems.

In conclusion, I feel the addition of a 1024 byte extended packed mode to protocols like XMODEM, will let them work well with these new modems. The 1024 byte packet mode lets users of these new modems obtain a reasonably high throughput. It also allows users of older modems to improve throughput when using good quality phone lines. You should try these new modems with caution, the performance varies greatly between various models. You may not obtain the performance you expect. Unless you can write off the cost in less than one year, it might be wise to delay your purchase for a while. With the current incompatibility between various manufacturers modems, you will likely be an island onto your self.


Thanks to Ed Cartier

by Stuart Baker

I would like to take this opportunity to thank Ed Cartier for the great job he did on organizing Compatibility '88. The annual Interchange meeting is a place to exchange ideas and learn about new products. This was the first Interchange meeting with a central location for participants to learn about products compatible with Concurrent's 3200 Series processors. The entire exhibit area was expertly organized by Ed Cartier. Thank you Ed, and keep up the good work for Interchange '89. I think everyone appreciates your effort. The presence of Compatibility '88 generated a lot of interest throughout the users.

Return to Index
Article Copyright 1988 Stuart J. Baker

This SBSW.COM page has been optimized for printing.
Web Content Copyright © 1997 - 2010 Stuart Baker Software. All rights reserved.

Please use our Feedback form to submit questions or comments about this web site.
Web Content Copyright © 1997 - 2010 Stuart Baker Software. All rights reserved.
This site was last modified: Wednesday, December 29, 2010