Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!van-bc!rsoft!mindlink!a780 From: Mike_Benna@mindlink.UUCP (Mike Benna) Newsgroups: comp.dcom.modems Subject: Re: Modem info for PC users Message-ID: <4670@mindlink.UUCP> Date: 3 Feb 91 02:59:25 GMT Organization: MIND LINK! - British Columbia, Canada Lines: 204 In article <3760.27a77a47@hayes.uucp>, tnixon@hayes.uucp (Toby Nixon) writes: > 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. Toby, thank you for helping to ensure that the information I am providing to people is accurate. I will incorporate some of the changes you suggest but first I think I should make some clarifications. Firstly, I must point out that perhaps you misunderstood who the article was directed at: Joe User who calls a Public PC BBS (i.e. IBM, Amiga, Atari ST, etc.); it was _not_ directed at people who call business-to-business, or even people who call overseas. Further, I would bet that 99% of the calls made by my target audience are not long distance. It is partly my fault for not identifying the audience explicitly; I will be sure to do so in the future. >> Link Protocols >> -------------- > In the industry, these are called "Modulation Techniques", not "Link > Protocols". Thank you for the clarification. I will make this change. > 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. "Data link protocols" may be the real industry name but I think that most people will be confused by that name. I feel it is important to have the term "error correction" somewhere in the name of the protocol since that is how it is referred to by most people. It also helps to distinguish them from compression protocols. >> 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. I am quite aware of that although I did not include them because I was restricting myself to 2400bps+ (i.e. "High Speed"). Perhaps some quick mention of these modulation techniques is in order. > "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". What you say is true however I argue that HST modulation can be referred to as a 'standard' (albeit a proprietary one) when trying to explain modem communications to my target audience. In general they do not care about CCITT recommendations, they only care about how many BBSes they can call and at what rate they may exchange data with those BBSes. > First, V.32bis also has, in addition to the capabilities of V.32, > operation at 7200 and 12000 bps, and a rapid rate renegotiation > [... text deleted ...] > 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. I am aware of the additional capabilities of V.32bis but 95% of the people in my target audience do not care about 300baud, 1200bps, 4800bps, 7200bps, or 12000bps. In general they only care about the maximum throughputs they will get with any particular type of modem. Thank you however for pointing out that V.32 compatibility is mandatory in V.32bis. I will be sure to mention this. >> HST14400: The upgraded HST9600 standard ... > > Again, it is not a "standard". Again, due to the large numbers of these types of modems in the PC BBS community I will call it a 'proprietary standard'. > 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. Really? I didn't know that. I will be sure to mention that in the article. > Please refer to it as "LAPM", not "V.42". Because V.42 must also support MNP4, you are right that I should make a distinction between LAPM connections and MNP4 connections. > 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). Does the consumer typically have control over the frame size? If not then the information is irrelavant to my article however I am grateful you have shared that information with us. By the way, don't worry so much about convincing me that LAPM is better than MNP4 - I'm already on your side. > I MUST note that it is EXTREMELY rare to see 609 throughput on an > MNP5 modem, even with BBS menus. > [... further technical explanation of why ...] Your argument may be technically correct however in a situation such as this there is no substitute for actual testing. I've since gone and captured a whole bunch of 'typical' BBS menus (again) and done some testing on how well they compress. The results: MNP5: 638cps, V.42bis: 813cps. It seems I was out a little bit in the first place but not in the direction you thought I was. > 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., From your wording I would assume that there is a reason that MNP3 can be implemented in software but MNP4 cannot. Is this true? Why? Also, how many of the currently installed modems support the 'Hayes AutoSync feature'? If it is any less than 25% then I won't ever expect to see any MNP-in-software vendors support it (just my opinion of course). > 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. This is all very true and also points further to the fact that I should have been clearer in identifying my target audience. >> - 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. In a quick survey of the BBSes around Vancouver I've found that the ratio of HST to V.32 support is about 4:1 and _all_ of the ones with V.32 also have HST. In fact the multi-line BBSes which support both usually have a ratio of 2 HST lines for every V.32 line. >> 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. I hope the only part of that you 'strongly disagree' with is the part about the number of V.32 BBSes out there :). Again you seem to be forgetting that _currently_ there are many more HST BBSes out there than there are V.32 BBSes (4:1 in Vancouver). I agree that this situation is changing and obviously Hayes is going to promote V.32 over HST as strongly as possible but that does not change the fact that HST boards outnumber V.32 boards by a margin which cannot be considered insignificant. As always, if a consumer wishes to call a particular BBS then he/she had better check which modulation techniques are supported. Given the option I would recommend V.32 but some people may not have the option. > P.S. In addition to being Principal Engineer in Hayes' Systems > [... text deleted ...] > Voice/Data/Fax Interworking for SG XVII, and editor for V.42 (wrote > several parts of it and V.42bis). When you finish up with a comment like this it sounds like you're looking for an argument and you want to make sure your credentials are on the table for all to see before we get too deeply into it. Don't worry, I believe you are getting a reputation for posting correct information, especially when it comes to the technical stuff. ---> Mike -- ---> Mike Benna, Vancouver, B.C., Canada MindSpan Technologies Corp - Video Game Design and Development UUCP: Mike_Benna@mindlink.UUCP or uunet!van-bc!rsoft!mindlink!Mike_Benna