Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!uunet!hayes!tnixon From: tnixon@hayes.uucp Newsgroups: comp.dcom.modems Subject: Re: Modem info for PC users (long) Message-ID: <3760.27a77a47@hayes.uucp> Date: 31 Jan 91 02:00:39 GMT References: <4616@mindlink.UUCP> Organization: Hayes Microcomputer Products, Norcross, GA Lines: 219 In article <4616@mindlink.UUCP>, Mike_Benna@mindlink.UUCP (Mike Benna) writes: > High Speed Modem Info for PC users > > > Written by Mike Benna, January 1991. > ... I think it's great, Mike, that you're trying to educate users on these issues. If you would, please allow me to correct some of the points in your article. I hope you'll update it and re-post. > Link Protocols > -------------- In the industry, these are called "Modulation Techniques", not "Link Protocols". Error-correction protocols are also called "data link protocols", because error-correction is a function of OSI layer 2, the "data link layer". I think it is important for you to correct this terminology throughout the document so that users aren't totally confused when they read other documents. > Note that there are many other protocols in use but it is > unlikely that you will encounter them in day-to-day PC use. Actually, people encounter Bell 103 and Bell 212 pretty frequently. > V.32: One of the 9600bps standards. It is not compatible with the > HST protocol. V.32 modems can send at full speed in both > directions at the same time. Most V.32 modems come with MNP > and/or V.42. "One of"? Actually, V.32 is the _only_ current international standard for dial-up 9600bps communications on voice-grade two-wire lines. It is incorrect to refer to HST, PEP/DAMQAM, Hayes ping-pong, or any other high-speed modulation scheme as a "standard". > V.32bis: The upgraded V.32 standard which runs at 14400bps in both > directions at the same time. In all other ways it is similar > to V.32. V.32bis is newly emerging (I don't think the > standard has even been totally finalized yet). When V.32bis > modems become available you can expect all of them to offer > V.32 compatibility. First, V.32bis also has, in addition to the capabilities of V.32, operation at 7200 and 12000 bps, and a rapid rate renegotiation capability to allow the modems to quickly change data rates up or down in response to changing line conditions. V.32bis _has_ been "totally finalized", in terms of the technical work on the text. It is currently being balloted among the CCITT member countries; the ballot closes on February 22nd. Finally, backward compatibility with V.32 modems is _mandatory_ in V.32bis modems, so you most certainly MUST expect it in modems claiming compliance to V.32bis. > HST14400: The upgraded HST9600 standard ... Again, it is not a "standard". > Once two of these modems get talking to one another they may try to > establish an error free connection using either MNP4 or V.42 (V.42 is > also known as LAP-M for Link Access Protocol for Modems).... > coming out just barely ahead of V.42. It should also be noted that > these two protocols are not compatible with each other and therefore > many of the newer modems on the market support both standards. V.42 includes TWO protocols: the primary protocol, LAPM, and an alternative protocol which provides backward compatibility with modems which implement MNP2-4. Therefore, ALL modems which claim compliance to V.42 MUST support BOTH LAPM and MNP4. > By getting two MNP4 or V.42 modems talking together you can expect to > get throughputs such as these: > > Link Rate Without MNP4/V.42 MNP4 V.42 > --------- ----------------- ------- ------- > 2400bps 240cps 287cps 285cps > 9600bps 960cps 1138cps 1124cps > 14400bps 1440cps 1707cps 1686cps Please refer to it as "LAPM", not "V.42". MNP4 has a fixed maximum frame size of 256 bytes, but LAPM can negotiate frame sizes from 16 all the way up to 4096 bytes. The reason you generally see slightly slower throughput with LAPM is that the _default_ frame size in LAPM is 128 bytes. Substantial testing showed that this provided the best performance when retransmission was necessary to correct for errors (resending 256 bytes can take a long time!) without overly impacting on throughput on clean lines. It is certainly acceptable to negotiate a 256-byte frame size in LAPM, in which case the performance of MNP4 and LAPM are _identical_ on clean lines -- 122% of the nominal modem bps rate (e.g., 292 cps on 2400bps modems). > Typical throughput table for MNP5 and V.42bis (in cps): > > Protocol: MNP5 | V.42bis > Link Rate Data Type: A B C | A B C > --------- ---- ---- ---- | ---- ---- ---- > 2400bps 254 489 609 | 285 768 928 > 9600bps 1013 1956 2440 | 1124 3072 3718 > 14400bps 1520 2934 3658 | 1686 4608 5574 I MUST note that it is EXTREMELY rare to see 609 throughput on an MNP5 modem, even with BBS menus. MNP5 works by compressing single bytes using a Huffman-like compression scheme. The smallest it can compress a single byte is 4 bits -- which means the best it can do is 2-to-1. The only exception to this is when you have long strings of _identical_ characters, such as long strings of spaces. In this case, MNP5 Run-Length-Encoding (RLE) compression kicks in, to compress up to 255 consecutive identical characters into as few as 12 bits. Of course, it's impossible for the DTE interface rate to keep up with that compression ratio, so even RLE normally can't do better than 4-to-1 or so. You'd only see 600+ cps in short bursts within a single display line, and never sustained over a long transmission (unless it was contrived purely for the purpose of inflating the compression performance, such as sending a file containing only a single repeated character). My estimated theoretical throughput numbers for V.42bis align with yours. However, it should also be pointed out that there is a lot of room in the V.42bis standard for variations between performance of manufacturer's implementations. This was _intentional_; a key element in the selection of the compression technique when we were writing V.42bis was the ability to have low-cost, low-resource implementations that would attain somewhat worse compression, and higher-cost, high-resource implementations that would attain close to the theoretical maximums. Depending on the available memory, processor speed, and quality of firmware implementation, users are likely to see quite a variety of "actual" throughput figures, differing from what you mention here. > Software MNP5 > ------------- > ... > The MNP protocol cannot be implemented fully from the computer side of > things. In order to run at full speed it must be able to do the > asynchronous to synchronous conversion and this cannot be done from the > computer, it must be done inside the modem. Actually, it _is_ possible to do a complete MNP3 (synchronous framing) implementation in a PC, if your modem has the Hayes AutoSync feature. But, alas, none of the MNP-in-software vendors have yet announced such a capability., > As of this writing (Dec '90) the only two standards which are > popular in the PC world are the USR HST standard and the V.32 (and soon > to come V.32bis) standard. You should make it clear that you're talking about the PC _BBS_ world here. In corporate environments, Hayes ping-pong and Microcom MNP6 have been much more widely installed than USR HST, and in UUCP environments, Telebit PEP is much more widely installed. In fact, PC-based BBSes is about the only place where you hear about HST being used much. > - Many other manufacturers are supporting the V.32 standard. Competition > seems to be driving the price of V.32 modems below that of the HST > modems (this was not always the case). In the future we can expect a > big difference between the two standards; V.32 modems will likely be > much cheaper in the long run than HST modems (even though V.32 modems > are more complicated to build). Now that major chipset manufacturers (e.g., Rockwell) have come out with good-quality, inexpensive V.32 chipsets, it is _much_ easier to build a V.32 modem than HST. Since there are no generally-available chipsets for HST, a manufacturer would have to design it from scratch in DSP, and only a very few manufacturers have that level of engineering expertise on-staff. > - Most public BBS's which support speeds higher than 2400bps only > support the HST standard. This is because USR used to offer Courier > HST modems to BBS operators at a reduced cost. This may have been true at one point. "A Majority" _might_ still be true. But there are over 500 BBSes using Hayes Ultra 96 V.32 modems now, and hundreds of others using V.32 modems from other companies, including USR. Also, the 9600bps access to data networks such as Telenet, Tymnet, and CompuServe is _only_ V.32. Many V.32 modem vendors (e.g., Hayes, USR, Practical Peripherals, Intel, others) still offer special sysop prices (typically, 50% off retail). The desire for universal compatibility is going to see HST modems replaced by V.32 and V.32bis modems very quickly. > - Compuserve recently purchased a bunch of rack-mount USR Dual Standard > ... > (They apparently purchased Dual Standard modems because they are the > only rack mount V.32 modems currently available.) They weren't the only ones available by any means. But USR's were probably the cheapest. CompuServe went through an extensive competitive bidding and evaluation process. > My feelings are that V.32 modems are technically superior to HST modems > in many ways and are likely to become common in the next few years. The > problem with this is that very few public BBS's support V.32 making a > V.32 modem almost useless at anything over 2400bps if the only places > you call are BBS's (you should check your favorite BBS yourself). Again, I strongly disagree. There are already hundreds, even thousands of V.32 BBSes out there, and the number is growing extremely quickly. -- Toby P.S. In addition to being Principal Engineer in Hayes' Systems Engineering department, I am also their representative in US and international standards committees related to modem and fax communications. I chair committee TIA TR-30.4 on DTE-DCE protocols, and Special Rapporteur (chairman of a technical working group) in CCITT Study Group XVII on DTE-DCE protocols, Special Rapporteur for Voice/Data/Fax Interworking for SG XVII, and editor for V.42 (wrote several parts of it and V.42bis). -- Toby Nixon, Principal Engineer | Voice +1-404-449-8791 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net