casey@CS.UCLA.EDU (06/02/88)
For those who haven't seen it yet, the June 1988 issue of BYTE magazine has an absolutely incredible article on modems (volume 13, number 6, pages 102-113). The article is clear, comprehensive, and interesting. It covers the current state of modem protocol standards and describes how some of the most popular high speed modems achieve their performance. SUMMARY: V.32 is a CCITT full duplex 9600 protocol for two wire telephone lines. It was adopted in 1984. It uses echo cancellation to sort out the interference caused by two senders operating at the same time. Unfortunately V.32 was ahead of its time and difficult to implement because it required such sophisticated techniques (high speed signal processors). Many companies responded to consumer demand for an immediately available high speed modem by modifying another, older CCITT standard, V.29 (V.29 protocol engines were/are readily available). V.29 is a full duplex protocol for four wire lines. It was adopted in 1976. The high speed modems designed around the V.29 engines of course have to play games in order to operate over two wire lines. I won't go into the details here - read the article. Many of these modems also incorporate various data compression techniques and almost all of them have error correction of one form or another. Again, read the article for the details - your time will be well spent. The article goes on to describe 13 currently available high speed modems, describing their communication protocols, and compression and error correction schemes. It then goes on to reporting the results of a fairly extensive series of tests which measured the modems' performance over clean and noisy lines. At the risk of getting sued for copyright infringement, I'll include one of the summary tables here: Manufacturer/ Typical line Noisy line Modem MAX AVE MAX AVE Protocol ------------------------------------------------------------------------ Case 4696/VS 8429 6422 4925 3274 V.29/V.27 Concord 296 Trellis 8842 8448 8861 8237 V.32 * Data Race BMX-VM 4963 4704 4829 4339 V.29 Data Race VM I 5520 5136 0 0 V.27 Fastcomm Turbo 2496 3475 2486 3341 2102 V.29 Hayes V-Series Smart Modem 9600 5002 4742 4973 4435 V.32 HDX Microcom AX/9624c 8304 6115 3926 2592 V.29 Racal-Vadic 9600VP 6442 5798 6461 5002 V.29 Telcor Accelerator 2496MA 9091 8256 9082 8362 V.22bis * Telebit TrailBlazer Plus 7152 5568 7229 5078 PEP Telenetics 9600E/V.32 9283 8995 0 0 V.32 * USRobotics Courier HST 8678 8083 0 0 Asym. TCM QAM Ven-Tel EC18K-34 7066 5414 7190 4704 PEP All MIN/AVE figures are bits per second (bps). Test is transmission of 81920 bytes of pseudo random data. Modem/computer connections were fixed at 9600 baud (the lowest common denominator). Full duplex modems (those marked with `*') were tested with full duplex data streams, all others with data flowing in only one direction (the half duplex modems exhibited very poor performance when full data streams were running in both directions). (The Cermetek, NEC, and Universal Data Systems high speed speed modems were not available at the time of publishing for the BYTE article and will be reviewed in a later article.) COMMENTS: As I said above, this is an excellent article and well worth the time to read it. The testing results are valuable to anyone considering buying a high speed modem (though it must be remembered that since almost none of these modems will talk with each other - availability of other modems of the same brand to talk to should also be considered for general use purposes, eg. the Trailblazer for USENET sites). One of the most startling results of the review is the performance of the Telcor Accelerator 2496MA. Using only 2400 baud protocol technology, it was second only to the two true V.32 modems tested for average transfer rates on typical lines, and topped the entire field hands down on noisy lines. This to me is nothing short of astonishing. The Telcor also appears to be practically immune to noise. Finally, it had the cheapest list price ($895) of any of the tested modems. The authors of the BYTE article were also impressed with the Telcor's performance and used it to justify prophecies of 38Kbps modems in the near future. One disturbing aspect of the Telcor is the fact that it accomplishes its miracles of throughput via a proprietary data compression and error correction technique. This bodes ill for the survival of the company unless they want to drop the price of their modems down to $300. At the current price, one's thought is: ``I'll only *ever* be able to talk to other Telcors. I wonder how many other people are going to buy one?'' My advise to Telcor would be to copyright or patent their technique (whichever legalism is appropriate) and license it out to other modem manufacturers at the very least. And if Telcor is truly far sighted, to simply publish their technique and propose it as a standard. They'll win either way in the long run because the consumer will perceive that they won't be stuck with an expensive 2400 baud modem. Publishing their technique would obviously go a lot further along those lines. FINALLY, QUESTIONS: Has anyone gathered any data to support the figures given above, especially for the Telcor 2496MA? Has anyone had any experience with the Telcor? Would anyone at Telcor be willing to debate the benefits vs. liabilities of the proprietary nature of Telcor's data compression, error correction scheme? Casey
wtm@neoucom.UUCP (Bill Mayhew) (06/03/88)
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!"
brad@looking.UUCP (Brad Templeton) (06/03/88)
Once again, the magazine testers don't get nearly the throughput out of their Telebits that we get in everyday use. Telebit really has to get their PR department working on making sure reviewers know how to test the modems. On a clean like I regularly get 1400 bytes uncompressed throughput out of my trailblazer. I haven't really done a lot of dirty line testing but I know a lot of you have. So I wouldn't trust the magazines a lot. -- Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473
dmk@dmk3b1.UUCP (David Keaton) (06/05/88)
One thing that caught my eye in the Byte article was the pair of graphs where one modem fell off a cliff when the signal to noise ratio got bad, and a PEP modem took a wild path down to zero throughput. Their explanation about how the PEP modem had to retrain at various noise levels doesn't quite make sense to me unless the modem had to readjust which frequencies it was using. In other words, we were probably seeing a graph of changes in the frequency response curve of their noise generator! -- David Keaton dmk%dmk3b1@uunet.uu.net uunet!dmk3b1!dmk
sewilco@datapg.DataPg.MN.ORG (Scot E. Wilcoxon) (06/06/88)
In article <431@dmk3b1.UUCP> dmk@dmk3b1.UUCP (David Keaton) writes: >One thing that caught my eye in the Byte article was the pair of graphs >where one modem fell off a cliff when the signal to noise ratio got bad, >and a PEP modem took a wild path down to zero throughput. Their >explanation about how the PEP modem had to retrain at various noise >levels doesn't quite make sense to me unless the modem had to readjust >which frequencies it was using. In other words, we were probably seeing ... The BYTE article did not mention the elapsed time of the test. The graph seems to have throughput peaks which are too jagged to have had a long period of time between modem frequency adjustments. Anyone have figures on how often a PEP modem hits a line change which requires frequency adjustment? -- Scot E. Wilcoxon sewilco@DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco Data Progress UNIX masts & rigging +1 612-825-2607 uunet!datapg!sewilco
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (06/06/88)
I don't have the article here, but I'm suspicious that none of the
data was over 960 cps. Did they run the serial line from the source to
the equipment to the modem at 19200 and let the modem do the throttling?
If not some of the data compression schemes will not work at all well.
I have seen figures showing 460 cps from a MultiTech 224E (MNP5) which
is nominally 2400, and 13000 cps on a Trailblazer. I'm curious, too,
about protocol used, since I know that some protocols work poorly with
slow turnaround, while others, like zmodem and window kermit, run very
well and at about 90-92% of line speed. I've seen this over some
connections which had about 500ms delay, and I assume they were satelite
links.
I'm going to read the article later this week, when I get a chance.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -medavid@ms.uky.edu (David Herron -- One of the vertebrae) (06/07/88)
In article <989@datapg.DataPg.MN.ORG> sewilco@datapg.DataPg.MN.ORG (Scot E. Wilcoxon) writes: >In article <431@dmk3b1.UUCP> dmk@dmk3b1.UUCP (David Keaton) writes: >>One thing that caught my eye in the Byte article was the pair of graphs >>where one modem fell off a cliff when the signal to noise ratio got bad, >>and a PEP modem took a wild path down to zero throughput. Their >The BYTE article did not mention the elapsed time of the test. The >graph seems to have throughput peaks which are too jagged to have >had a long period of time between modem frequency adjustments. Anyone >have figures on how often a PEP modem hits a line change which requires >frequency adjustment? Read the similar article in Data Communications -- it has a better explanation of the test procedure. The thumbnail sketch of the test procedure: They simulate a phone company. That is, there's a local loop, a box converting to a 4-wire circuit, a noise inserter, another box converting back to a 2-wire circuit, and another local loop. The noise inserter is programmable to insert any desired signal-noise ratio into the system -- sorry I don't remember details about the type of noise. At each noise setting they transmit at least 80K of data using their protocol and measure how long it takes to transmit the data. Then they bump the noise by one notch (1 db?) and do it again. They keep this up until the modem fails or something like that. The 80K of data would take 80 to 100 seconds to transmit through these modems, which would be far and away enough time for the trailblazers to handle re-training and the like... -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- s.k.a.: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <---- <---- Goodbye RAH.
chip@vector.UUCP (Chip Rosenthal) (06/09/88)
In article <1256@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: >I'd like to see ... how well modems stand up to over-voltage pulses on the >phone/power line... Several of the cheap modems we have seem to have died >prematurely .. presumably from line spikes. One of the more amusing cheapie >modems used two 1N4004 diodes connected back-to-back. This doesn't make sense to me. Any modem needs to have a DAA which meets FCC part 68 approval before it can be hooked up to the public network. Essentially, this verifies that the equipment can take a lightning bolt and not blow up or harm the network. I would tend to think that there is a bit more energy in a lightening bolt than a line spike. I assume your cheapie modem had a sticker with an FCC registration number. Maybe you want to check and see if they are for real. Disclaimer: We sell a DAA, but I don't work on it, nor do I work on modem products. There could be very well be something different between the requirements for modems and the requirements for the telecom gear I'm more used to. -- Chip Rosenthal /// chip@vector.UUCP /// Dallas Semiconductor /// 214-450-0400 {uunet!warble,sun!texsun!rpp386,killer}!vector!chip I won't sing for politicians. Ain't singing for Spuds. This note's for you.
brad@kontron.UUCP (Brad Yearwood) (06/09/88)
I cannot help but be more than skeptical about Byte's observations of
8200 bit/second average full duplex throughput on the Telcor Accelerator
2496MA if it is truly using V.22-bis modulation as claimed in the
article.
Does V.22-bis not place a hard and fast upper bound of 2400 bits/second of
non-redundant information flowing across the channel in each direction?
If Casey Leedom transcribed the chart correctly in his posting, the
claim is made that the Telcor 2496MA was attaining the observed throughput
in full duplex transmission. This precludes non-standard uses of V.22-bis
modulation in some sort of adaptive duplex mode (similar to one of the
Trailblazer's tricks), which might be able to roughly double the throughput
but in only one direction at a time.
I am ready to believe that a clever compression method could achieve about
a 3:1 compression factor for English text, assuming an 8000 word typical
working vocabulary and 5 characters (plus a space) per average uncompressed
English word.
I am ready to believe a compression factor of a somewhat better than 2:1
for arbitrary strings of decimal digits.
I am ready to believe that Byte's pseudorandom data source was in fact
periodic, and that its period was significantly less than the total
amount of information transferred in their test. In such a case, a
compression scheme that tabulates recurring sequences in its input stream
and instructs the output to replay these sequences with a relatively small
amount of channel code saying "replay(table_index,howmuch)", could give
results that are very misleading for much real-world data. Of course, such a
compression scheme could perform well for other types of real world data,
particularly texts in English or other human languages.
But unless the modem has a dictionary for a large subset of that language
built-in, the initial occurrence of each recurring sequence must be
transmitted at a rate no better than the modulation rate of the channel,
though some additional speed can be gained relative to the async. input
by framing less frequently than per-character, and (on ASCII input, but
not on pseudorandom or random input) by re-encoding from ASCII characters
to something more dense.
I am not ready to believe that any V.22-bis modem, no matter how
clever its compression, can pass any more than 2400 bits/second of
arbitrarily chosen information concurrently on both the forward and
reverse channels.
Byte's throughput figures for the Telcor 2496MA are simply not credible
for arbitrary (truly random) data, LZW-compressed Usenet news, low-order
bit planes of gray scale images of typical natural scenes, or any source with
little redundant information, and are even less credible for full-duplex
transfers of such information.
Certainly, with much (though not all) real-world data, there are significant
throughput gains available through clever compression. Adaptive duplexing
and protocol spoofing are clever ways to allocate the bandwidth made
available by whatever modulation technique has been chosen and to work
efficiently over long-delay channels, such as satellite connections.
But a modem working with V.22-bis modulation, no matter how clever the
compression, will never be able to send low-redundancy information
as quickly as a modem with more capable modulation, such as V.32 or
Telebit's DAMQAM. And a good implementation of V.32 will give better
full-duplex performance than Telebit's DAMQAM with its adaptive duplexing,
at least over channels of comparable and good quality.
Does my skepticism of Byte's observations, particularly on the Telcor
2496MA, make sense, or should I abandon an admittedly less-than-
totally-informed faith in information theory in favor of something
new which, for lack of a better name, I will call tooth fairy theory?
I'll stick to my Trailblazers for now, thank you. Though Telebit's
ads claiming 19200 bits/second are not strictly defensible, Telebit did make
available in a relevant forum (here) sufficient information about their
techniques to allow an informed (influenced to no small extent by that very
nice discount) choice. I'm very pleased to see 90K bytes sent via uucp
from here to New York in under 2 minutes, where the same file failed
repeated retries in 45 minutes of phone time to the same site with a
1200 baud modem.
This is not to say that Telcor might not have a good modem with clever
compression and/or channel management that might give good performance
on much, but not all, real-world data, even if it uses exclusively
V.22-bis modulation.
Either Byte's evaluation procedure was inadequate, or the Telcor is
not a V.22-bis modem (perhaps through misunderstanding by the reviewers),
or I have even less a grasp of the bare rudiments of information
theory than I believe and am therefore an ass.
Brad Yearwood
Kontron Electronics {voder, pyramid}!kontron!brad
Mountain View, CAjames@bigtex.uucp (James Van Artsdalen) (06/11/88)
IN article <9574@e.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) wrote: > Read the similar article in Data Communications -- it has a better > explanation of the test procedure. Was there any mention of the contents of the test file? That can make a lot of difference. I would like to assume they used several different files with different contents and averaged the results, but it doesn't sound like it. -- James R. Van Artsdalen ...!ut-sally!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
henry@utzoo.uucp (Henry Spencer) (06/16/88)
> ... Any modem needs to have a DAA which meets > FCC part 68 approval before it can be hooked up to the public network. > Essentially, this verifies that the equipment can take a lightning bolt > and not blow up or harm the network... Ho ho. No. Not quite right. The DAA is to protect the network. Period. The equipment is on its own. (Actually, it would not surprise me if some of the commercial DAAs included protection for the equipment, but that is *not* the purpose of a DAA, and I for one wouldn't depend on the DAA for that.) Some manufacturers do a better job than others on input protection for their equipment. -- Man is the best computer we can | Henry Spencer @ U of Toronto Zoology put aboard a spacecraft. --Von Braun | {ihnp4,decvax,uunet!mnetor}!utzoo!henry