Mike_Benna@mindlink.UUCP (Mike Benna) (01/29/91)
High Speed Modem Info for PC users
Written by Mike Benna, January 1991.
Because of the confusion people seem to have related to all the new
advances in modem technology I thought it was about time that somebody
compiled the relevant information into a single document. I have now
done so with this article in the hopes of clearing up many of the
mysteries and misconceptions about modems which operate using MNP and
V.42 style protocols.
Within this article, please note that some of the table values have been
derived from actual testing whereas others have been calculated based on
the theory behind the operation of all the protocols involved. All
table values assume clean (i.e. noise free) telephone connections and a
computer which is fast enough to feed the modem all the data it wants
and can accept all the data the modem gives to it.
First of all, a short glossary might be in order to clear up the most
common terms:
cps : Characters per second (usually used to measure the effective
throughput from the source computer, through the modems, and
into the receiving computer). In the end, this is the only
number which you should really care about.
bps : Bits per second (usually used to describe the raw data link
between two modems or between the modem and the computer). Note
that this is _not_ the baud rate.
baud : The single most often misused word in telecommunications. Most
people really mean "bits per second" when they use this term.
For example 2400bps modems only run at 600 baud and 9600bps V.32
modems only run at 2400 baud. If you don't know what a baud is
then you should probably be using 'bits per second' instead.
Next, you can probably forget most of what any salesman has told you;
most PC salesmen do not fully understand this stuff either. Don't blame
them however, they usually have the disadvantage of having read sales
literature from the manufacturers which was designed to be misleading in
the first place. Your best bet is to read this article and then go to
the store and test the hardware you think you want to purchase.
Link Protocols
--------------
In trying to explain how the various modems communicate I will start at
the lowest layer you care about: the link protocol. These protocols
describe the standard methods which the modems use to talk to each
other; they have nothing to do with error correction or data
compression. Note that there are many other protocols in use but it is
unlikely that you will encounter them in day-to-day PC use.
The rates described in the link protocol descriptions are often called
the 'link rates'; they are not necessarily the same as the rate between
the modem and the computer.
V.22bis: 2400bps (this applies to _most_ 2400bps modems). Normal
V.22bis (i.e. without MNP or V.42) is capable of a maximum
sending rate of approx. 240cps in both directions at the same
time.
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.
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.
HST9600: The U.S. Robotics 'High Speed Transfer' protocol. It offers
9600bps in one direction and 300bps in the opposite
direction. It is only available from USR in their Courier
HST and Courier Dual Standard modems. The USR Courier
HST9600 modems are no longer for sale from USR (they only
sell the 14400 models).
HST14400: The upgraded HST9600 standard which runs at 14400bps in one
direction and 450bps in the other. Again, it is only
available from USR in their Courier HST and Courier Dual
Standard modems. These modems are still compatible with
HST9600 modems but not with any others in HST mode.
note: None of the above standards are compatible with FAX machines.
Error Correction
----------------
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). There are
other protocols as well but these two are by far the most common. Both
of these protocols perform an asynchronous to synchronous conversion
which allows them to avoid sending start and stop bits. In general this
increases throughput for all data (even compressed files) by about 20%
(25% increase due to not sending the start/stop bits and approximately
5% decrease due to error correction and sync data). There is only a
slight difference in throughput between these two protocols with MNP4
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.
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
Data Compression
----------------
The next layer of standards which can be added is data compression.
The two common data compression protocols are MNP5 and V.42bis (not to
be confused with V.42 which is an error correction protocol).
Data compression works similarly to programs like PKZIP except that they
compress 'on-the-fly' as you send the data to the modem. In general, if
you are sending files which are already compressed with a program such
as PKZIP then there is no advantage to turning on data compression in
your modems. In fact, if you are using MNP5 then you should disable
data compression (go back to MNP4) before sending compressed files
because it will actually take longer to send with MNP5 than it will with
MNP4. V.42bis on the other hand is smart enough to realize that it can't
compress the data any further and it turns itself off until it decides
that it will be useful again.
Data compression has its biggest advantage when you are reading text
which may repeat itself frequently (e.g. ANSI codes and menu boxes have
a lot of redundancy and consequently they compress very well). Because
different types of data have different amount of redundancy, I've broken
the throughput table into several types of data:
A) Compressed data (e.g. .ZIP, .ARC, .SIT, etc. files).
B) Regular text (e.g. this article).
C) Typical BBS Menus.
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
As you can see V.42bis does a better job than MNP5 for all types of
data and has the advantage that you can always leave it on (even if you
are going to be doing file transfers of compressed data).
Software MNP5
-------------
Some 2400bps modems for sale today offer MNP5 compatibility in software,
not in hardware (read the box carefully). If the modem manufacturer is
offering software MNP5, he is really selling you a regular 2400bps modem
(without any MNP capability) and including a terminal program for your
PC which allows any modem to perform some of the functions of the MNP
protocols. In fact, if you were to buy any old 2400bps modem you could
then go out and purchase a terminal program which had software MNP
support.
Confused? I'll try to clear this up further...
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. At 2400bps these are some
of the typical throughput speeds you might expect to encounter for
software MNP5:
No MNP Hardware MNP5 Software MNP5
------- ------------- -------------
Compressed data 240 cps 254 cps 193 cps
Regular text 240 cps 489 cps 371 cps
Typical BBS Menus 240 cps 609 cps 487 cps
As you can see from the table, software MNP5 is not nearly as efficient
as hardware MNP5 and it also means that you cannot choose your terminal
program - you must use the one which supplies the software MNP5 support.
Since software MNP4 does not benefit from the async to sync conversion
it will offer you an error free line but it will only run at about 228
cps (instead of the regular 240 cps you will get with no MNP support).
Not Getting the Throughputs I claim?
------------------------------------
The throughput numbers I've provided in this document are the raw total
throughput numbers. Please note that this is not the same as what you
would measure using a typical file transfer protocol. For example,
Zmodem normally gets about 234cps on a 240cps link, or to put it another
way, Zmodem runs at 97.5% efficiency. Therefore to calculate your
expected throughput using Zmodem you simply need to multiple the numbers
I've provided by 0.975. Of course in this complicated world of
communications no single number is enough: Zmodem with the Moby-Turbo
option usually offers about 99.2% efficiency (238cps on a 240cps link).
Also note that non-streaming protocols (such as Xmodem and Ymodem) do
not fair as well as streaming protocols (such as SEAlink, Ymodem-G, and
Zmodem) on higher speed links because propogation delays and response
times do not necessarily decrease when the link rate increases.
Which to buy: an HST or V.32?
-----------------------------
Many people in the PC world who want to upgrade to a modem which goes
faster than 2400bps are faced with the question of which standard to go
with. 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.
In this section I won't tell you which to buy but I will give you some
information which may help you to make your choice:
- Only USR is currently building HST modems. If you wish to get an HST
modem it must come from USR. The advantage of this is that you aren't
likely to run into compatibility problems when using the HST standard.
The disadvantage is the price: USR modems aren't cheap (but they are
of good quality).
- 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).
- USR makes a modem called the 'Courier Dual Standard' which supports
both HST and V.32 protocols in the same modem. It's disadvantage is
cost.
- 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.
- HST modems are only high speed in one direction at a time. This
causes severe speed degradation problems during some kinds of file
transfers. In all cases it is best to try before you buy.
- One very popular type of modem in the Unix world is the Telebit. The
older Telebit modems are not compatible with either HST or V.32 modems
but many of the newer ones (if not all) have V.32 support added to
them (in addition to their native modes). This is further evidence
that V.32 has more long term potential than HST.
- Compuserve recently purchased a bunch of rack-mount USR Dual Standard
modems but is unwilling to enable the HST mode on them because once
they start supporting HST mode they feel they must continue to do so
for years into the future and they do not want to be locked into
purchasing more modems from only one supplier. It seems they also
feel V.32 is going to be the high speed modem choice of the future.
(They apparently purchased Dual Standard modems because they are the
only rack mount V.32 modems currently available.)
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).
Disclaimer
----------
The information provided in this document is for the convenience of the
BBS and uunet community. It may be freely distributed but may not be
modified. There are no warranties as to the accuracy of anything which
has been written here. In all cases if you are buying any computer
equipment (including modems) it is best to test the setup you wish to
purchase before purchasing anything. Remember: if it won't work in the
store then why would you expect it to work at home?
This document is Copyright (C) 1991 Mike Benna.
--
---> 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_Bennatnixon@hayes.uucp (01/31/91)
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
Mike_Benna@mindlink.UUCP (Mike Benna) (02/03/91)
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
johnboyd@LOGDIS1.OC.AFLC.AF.MIL (John Boyd;CRENP) (02/03/91)
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.
tnixon@hayes.uucp (02/05/91)
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
Mike_Benna@mindlink.UUCP (Mike Benna) (02/09/91)
In article <3767.27ad95b3@hayes.uucp>, tnixon@hayes.uucp (Toby Nixon) writes: > Mike Benna writes: >> 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. My test procedure: 1) Call a local BBS with my capture buffer open. 2) Go through almost all of the menus on the system. 3) Log off. 4) Edit my capture buffer to remove all the stuff in between the menus, leaving only the menus themselves. 5) Remove any duplicate menus. 6) Transfer the resulting file (52K) from one machine to another using MNP5 compression and V.42bis compression at 2400bps. 7) Multiply the results by (240/238) to compensate for Z-modem overhead. Potential problems in my method: 1) ANSI codes are not recorded by my term program. This could change the results either way depending on the repetitiveness of the codes. Typically codes are similar for an entire menu (e.g. the color setting codes will be repeated several times). 2) When calling a BBS you will often go through the same menu several times. Depending on how long the compression algorythm 'remembers' things, this can improve throughput even more. 3) I am only testing the compression capabilities of one modem. Some modems may be more efficient, others may be less. The modem in question (the sending modem) is a USR Courier V.32. Also, I'll try to anticipate your next question: Here's a typical sample of the BBS menus I used in the test. Note that I've converted the IBM graphics characters to regular ASCII characters to avoid any 8th bit problems on the net. +---------------------------------------------------------------------- -+ | A Local Vanouver BBS MAIN MENU | +---------------------------------------------------------------------- -+ | <C>-CHAT MODE <E>-Exit System | | <B>-Bulletins Section <F>-File Transfer Areas | | <M>-Message Base Areas <O>-Online Callers | | <P>-Page the SysOp <R>-Recent Callers to System | | <S>-System Configuration <V>-Voting Booth Area | | <#>-System and User Statistics <!>-Special Conference Topics | | <D>-Database Area <*>-Menu Help File | +---------------------------------------------------------------------- -+ Note that there is a large amount of white space and other repeated characters sequences. >> 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've gotten several pieces of email from around North America which would indicate that indeed Vancouver seems like a 'pocket' of HST's. In any case things are changing here as well; there are more V.32 BBSes popping up all the time. ---> 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