Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!tut.cis.ohio-state.edu!mandrill!neoucom!wtm From: wtm@neoucom.UUCP (Bill Mayhew) Newsgroups: comp.dcom.modems Subject: Re: BYTE high speed modem article and the Telcor Accelerator 2496MA Summary: High baud-rate modems don't guarantee throughput Keywords: BYTE magazine article, high speed modems, wild compression results Message-ID: <1250@neoucom.UUCP> Date: 2 Jun 88 18:21:07 GMT References: <12997@shemp.CS.UCLA.EDU> Organization: Northeastern Ohio Universities College of Medicine Lines: 99 One thing that dismayed me about the article in the June 1988 issue of Byte was that the authors failed to underscore how very important it is to consider the modem and software together as a system. In fact, the Trailblazer's (just to mention one) special internal support of the Christensen (xmodem) protocol, Kermit and uucp g-protocol was not mentioned at all. One thing that we've found is that turn-around delays on the non-v.32 modems vary widely. The turn-around delay as the modem switches active communications direction can really devastate short packet length protocols like Kermit and uucp-q, well .. xmodem too. The delays between packets often are longer duration than the data packets themselves. Some software such as the newer incarnations of of Kermit and Relay Gold (a commercial product) support long packets, and are thus not bothered by turn-around delays. These products (correctly??) assume that most of the error correction can be handled by the modem, thus the majority of packets won't need retransmission. I personally have tried 3 v.32 modems: the UDS, Concord, and AT&T's. I couldn't get the Concord to talk to the UDS or AT&T for some reason. The AT&T and UDS modems worked just fine. We used them under admittedly optimum conditions over a local dedicated unconditioned twisted pair. Concord claims that their modem has much better than average performance, but we didn't notice any better performance over UDS or AT&T. Perhaps on bad lines...? I'd pick the UDS because it is substantially less expensive than AT&T. Since the Concord would only talk to its own kind (at least in our tests), I would avoid it. v.32 modems seem to provide about 80 - 90% the throughput of a piece of wire with uucp under optimum conditions. I think the slow-down is due to the propagation dealy inherent in the modulation and demoduation process. This is were Concord claims superiority in reducing delay. Both the UDS and AT&T modems had very nice front panel controls that were quite easy to figure out even without much if any assistance from the manual. In the case of the UDS, I didn't have to look at the manual at all to get it properly set up. With the Concord, there are a lot of film-type pushbottons and a big bank of dipswitches in the back; the manual is very necessary. The AT&T has a constellation generator card as an option, so that you can look at the carrier pattern on an oscilloscope if that tickles your fancy; most people won't care, I think. I have tried 4 of the hybrid/v.29 modem: Telebit, Racal-Vadic, US Robotics HST, Microcom. The Ralcal modem never did work quite right; it was full of jumper wires on the PC board. I think some might have been missing or miswired, as the modem's operation was too erratic. In general, the Racal was difficult to set up and had a cluttered front panel. The US Robotics is a very nice modem and quite attractively priced. On uucp, the USR HST "only" managed about 400 char/sec becuase the g-protocol didn't get along very well with the delay. It is my understanding that USR HSTs are used quite extensively on the FIDO network, though I have no performance data handy. The HST is qualitatively a very impressive performer when I am on line at a terminal. The response was quite zippy. Once again, struck with bad luck, one of the pair of Microcomm 9624 modems died only about 5 minutes after we turned it on. We didn't get enough data to draw any conclusions. The one remaining Microcomm, however, did perform excellently at 2400 baud. The quality of consturction in the Microcomm product is quite good, so I am surprised we had trouble. Must be my luck. My Telebit experience has been with the version 3 firmware (Not the Trailblazer Plus). We've gotten nice results with it for UUCP with xfer rates of up to 960 characters/sec between our sites. The version 3 firmware does have a fairly long turnaround delay when typing at a terminal. When using vi, I'd go at 2400 baud; save 9600/19.2 for reading news where not much interactiveness is required. Quite contrary to the findings of Byte, I've found that the Telebit is the most tenacious of the lot we've tried. Only sustained shouting and dialing DTMF tones from an extension phone on the same line would cause the Telebit to drop the connection. All the others would break the connection when dialing DTMF tones; usually just lifiting the handset was enough to break the connection. So far we haven't had a Trailblazer drop a connection in PEP mode under normal operating conditions. Personally, I value the tenacity with which the connection is maintained even more than the ultimate baud rate achieved. A modem that stays connected though heavy impulse interference at a lower speed is likely to get better thoughput than one that has to keep redialing the connection. The figures provided by Byte are most welcome and useful, but they really only tell a rather small part of the whole story. My recommendation would be to focus most on picking a particular communications software package, and then go out and purchase modems that work best with the product as per the software house's recommendations. Field experiences often tell much more than the numbers. --Bill wtm@neoucom.UUCP "Look Ma, no '>'s!"