Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!ucsd!ucbvax!LOGDIS1.OC.AFLC.AF.MIL!johnboyd From: johnboyd@LOGDIS1.OC.AFLC.AF.MIL (John Boyd;CRENP) Newsgroups: comp.dcom.modems Subject: Modem info for PC users Message-ID: <9102041816.AA22340@logdis1.oc.aflc.af.mil> Date: 3 Feb 91 15:45:49 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 133 Mike_Benna@mindlink.UUCP (Mike Benna) writes: to Toby Nixon > > High Speed Modem Info for PC users > > > Written by Mike Benna, January 1991. > >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 If that is your target audience, why the bandwidth here? TN> Error-correction protocols are also called "data link TN> protocols", because error-correction is a function of OSI layer 2, TN> the "data link layer". I think it is important for you to correct TN> this terminology throughout the document so that users aren't TN> 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. In the beginning of your document you could merely state what the 'industry' calls it, and then use whatever term you'd like for clarity's sake as long as THAT remained constant throughout the body of YOUR document. > Note that there are many other protocols in use but it is > unlikely that you will encounter them in day-to-day PC use. > TN> 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. Since you've established that your target audience is 'Joe User', Joe is likely to encounter the terms Bell 103 and Bell 212 quite frequently in any introductory texts he might find, *and* in the docs with the modem, if for nothing other than history's sake. TN> "One of"? Actually, V.32 is the _only_ current international TN> standard for dial-up 9600bps communications on voice-grade two-wire TN> lines. It is incorrect to refer to HST, PEP/DAMQAM, Hayes TN> ping-pong, or any other high-speed modulation scheme as a TN> "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. By mis-applying the use of the word standard, you merely encourage Joe User, and all those who read your material to mis-apply the term in the same way. This only serves to obscure the definition of the word 'standard'. Also, I would contend that a great many users do now, in fact, 'care about CCITT recommendations' since, as we move to improved communications abilities/equipment, true international standards will, and should, become more of a concern. The longer that you,I, or anyone who teaches those new to communications, perpetuate the myth that 'international standards don't matter'; the longer those incompatibilities will exist. As the frame of reference for common rules increases, the concern for compliance should increase. > HST14400: The upgraded HST9600 standard ... > TN> 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'. Isn't that an oxymoron? I believe 'proprietary protocol' is more appropriate. >> - 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. TN>> My feelings are that V.32 modems are technically superior to HST modems TN>> in many ways and are likely to become common in the next few years. The TN>> problem with this is that very few public BBS's support V.32 making a TN>> V.32 modem almost useless at anything over 2400bps if the only places TN>> you call are BBS's (you should check your favorite BBS yourself). > TN> Again, I strongly disagree. There are already hundreds, even TN> thousands of V.32 BBSes out there, and the number is growing TN> extremely quickly. >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. By making the statement that 'HST boards outnumber V.32 boards' it seems that you believe that HST 'is' the market. That is simply not so. Personally, I stay away from Courier, for the simple reason that they believe that you can't buy anywhere else, and act like it. I try like heck NOT to support proprietary versions of *anything*, although admittedly not always possible. The 'modem dumping' is the only reason that the HST is as prevalent as it is among BBSs. Remember, in the beginning, there was the PC, then along came Macintosh, for which there was no software. Somebody had to jump ship, or it wouldn't have gotten where *it* is today. But let's not digress too far. >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. So would I. The more that the techies/gurus recommend to Joe User that they stay with real standards, and shy away from proprietary protocols/methodologies, the sooner we can get to a level playing field, wash the incompatibilities away, and bring prices down and features up. johnboyd@ocdis01.af.mil ============================================================================ "Preserve your memories... The rest ends up in a garage sale" - Ferris Beuller Disclaimer - If I express an opinion, the Air Force will deny I know what I'm talking about.