Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!uunet!hayes!tnixon From: tnixon@hayes.uucp Newsgroups: comp.dcom.modems Subject: Re: Modem info for PC users Message-ID: <3767.27ad95b3@hayes.uucp> Date: 4 Feb 91 17:11:15 GMT References: <4670@mindlink.UUCP> Organization: Hayes Microcomputer Products, Norcross, GA Lines: 81 In article <4670@mindlink.UUCP>, Mike_Benna@mindlink.UUCP (Mike Benna) writes: > "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. Oh, I wasn't suggesting that you eliminate the term "error correction", but was expressing concern that your use of "link protocols" instead of "modulation techniques" might cause some people to be confused since the most common use of "link protocols" is in reference to "error correction", not modulation. No problem. > Does the consumer typically have control over the frame size? No, it is actually rare for a modem to provide a register to control the maximum frame size. Hayes modems are among the few that do so. > 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. It seems from your comment that you're using a file compression program rather than actual modem implementations. Is that true? I'm very interested in your actual testing method, particularly since it would seem to be difficult to get an "average" compression ratio for BBS menus while actually logged on. > 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). MNP2 refers to async framing with 64-byte frame size. MNP3 refers to sync (HDLC-like) framing with 64-byte frame size. MNP4 refers to 256-byte frame size and condensed frame headers for lower protocol overhead. MNP4 "optimizations" (as Microcom calls them) can be used with _either_ MNP2 or MNP3 framing. Thus, yes, it is easy to implement MNP4 in software. The hard thing to do in software is the synchronous framing. Most existing MNP software is MNP2/4/5. > 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. I think the actual ratio all around North America might be quite different from just Vancouver. HSTs are sometimes concentrated in pockets, since people want to be able to communicate in high speed with other modems; a move to convert to V.32 usually is done gradually. I think it will happen quite a bit faster now that CompuServe has V.32 access and users are able to buy V.32 modems (from PPI, Intel, etc.) for a good bit less than HST modems. > 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. Really, its just that I hate to make such an extensive series of comments without you knowing who I am or where I'm coming from, particularly my work on the standards you were describing. I didn't know whether or not you were already familiar with my background, and didn't want you to think I was just another know-it-all spouting off. Thanks for the comment about "reputation", by the way; I do try very hard to remain objective and non-confrontational. -- Toby -- 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