Monster Media 1993 #2

home *** CD-ROM | disk | FTP | other *** search

/ Monster Media 1993 #2 / Image.iso / magazine / aum006.zip / FILE5.006 < prev next >

Wrap

Text File | 1993-07-21 | 34KB | 643 lines

High Speed Modems We have received numerous messages asking about high speed modems, their capabilities and compatibility between modems from different manufacturers. The following text basically discusses the US Robotics HST 9600 bps modems and the Hayes V-Series 9600 bps modems. It also covers the subject of v.32 modems. 1) The old USR HST had a top transmission speed of 9600 bps. This is before taking into account any kind of MNP compression. Typical throughputs with the old HST ranged from 1150 cps on a compressed file with the modem- compression-DISABLED to 1900 cps on a regular text file with modem- compression-ENABLED. The HST will only transmit at 9600 bps when connected to another HST but will connect at 300/1200/2400 baud to other standard modems. 2) The new USR HST (termed the 1440) is able to transmit data at 14400 bps (again, this is before taking into account MNP compression, etc). Typical throughputs with the new HST will range from about 1500-1700 cps on a compressed file with modem-compression-DISABLED to about 2300-2400 cps on a text file with modem-compression-ENABLED -- this is assuming that you've opened your comm port at 38400 bps. The HST will only transmit at 9600 bps when connected to another HST but will connect at 300/1200/2400 baud to other standard modems. 3) The Hayes V-Series 9600 modems are similar to the old USR HST described in #1 above. You will typically see throughputs as high as 1900 cps on text files but only about 960 cps on compressed files. The Hayes V-Series 9600 will only transmit at 9600 bps when connected to another V-Series 9600 modem but will connect at 300/1200/2400 baud to other standard modems. 4) Hayes has recently begun shipping its V-Series modems with new ROM chips in them giving them v.42 compatibility. This means that the V-Series 9600 modems can now provide an error-corrected session when connected to any regular MNP modems at 2400 bps. This is because v.42 implements MNP levels 1 through 4 (which excludes MNP compression). You will typically see throughputs of about 260-280 cps on a 2400 bps line due to MNP's stripping of the start and stop bits. 5) The v.32 modems (such as those made by US Robotics and MultiTech) run at 9600 bps and will give you similar throughputs to those described in #1 above (i.e. v.32 will give you slower transmission speeds than will the new HST's running at 14400 described in #2). However, the advantages of v.32 are that it provides you with better "interactive response times" (such as when typing) and that because v.32 is a CCITT "standard" they will connect at 9600 bps to modems made by OTHER manufacturers. By "other" I mean that you can connect US Robotics v.32's to MultiTech v.32's to any other v.32's. The v.32 standard appears to be one that remain for some time to come. so purchasing a v.32 modem may be a better investment if you are concerned about future compatibility. However, v.32 still costs more than the proprietary standards such as the HST 9600 or the V-Series 9600. 6) The USR Dual Standard is BOTH a v.32 and an HST modem. When it is in the "HST mode" everything said in #2 above (about the new 1440 HST's) is true. When it is in "v.32 mode" then everything said in #5 (about v.32 modems) is true. In other words in v.32 mode you will not get the full speed advantage of the Dual Standard for file transfers. However, one BIG advantage to the Dual Standard is that it is compatible not only with the v.32 standard but with all of the existing HST modems as well. This may or may not be an advantage for you depending on which modems you frequently dial into or which modems dial into you. 7) Hayes is working on a v.32 modem that is similar to the v.32 description given in #5 above. I cannot comment further on this modem due to lack of details that have been given to me. NOTE: Another commonly asked question is about the differences between v.32 and v.42. v.32, v.32bis, v.42, v.42bis .. it's enough to drive you crazy! With so many v. (pronounced VEE DOT) standards you can get confused just thinking about them and even more confused if you try to pronounced them all in the same sentence. I'm going to attempt to explain the standards below in hopes of clearing some of the air surrounding these topics. What is the v.32 standard? ========================== The v.32 standard is a "modulation" standard. I like to compare it to the AM and FM standards used in radio broadcasting. Not only are they at different frequencies but they use different modulation techniques. There are different modulation standards for 300, 1200 and 2400 baud. The v.32 standard is a full duplex (data going both ways simultaneously at the rated speed) standard for 4800 and 9600 bps connections. What about v.32bis? =================== The "bis" means simply that it is an enhanced v.32 standard. Modems incorporating v.32bis are capable of transmitting data not only at the 4800 and 9600 bps standards but also at the higher 12000 and 14400 bps standards. Again, like the slower v.32 speeds the data can move in both directions simultaneously at the rated speed. So what is v.42 all about? ========================== The v.42 standard is an error correction standard. It is a method by which data is packetized and sent between modems to ensure that the data that arrives at the receiving end is the same as what was transmitted. MNP is another error correction standard. In fact, the v.42 standard includes MNP as an "alternate" method in case a modem is not v.42 compliant .. in other words v.42 modems can connect with MNP modems and achieve a "reliable" connection. Then v.42bis is an enhanced v.42? ================================= Yes. The v.42bis standard adds a high level of data compression to the error correcting facilities built into the v.42 standard. For example, an ascii text file that is 100K in length could, while being transmitted, be compressed down to just 25K making a 4:1 reduction in size. On the receiving side the transmitted data is expanded out to the original 100K size. In effect, the transfer rate of the modem can be double, triple or even quadruple the rated speed of the connection by compressing the data before transmitting it and uncompressing it on the other end. It should be noted that this type of data compression, while very useful for downloading ascii files, bulletins, messages, etc, is useless when downloading ZIP or ARC files which are already compressed. What about v.32 and v.42 together? ================================== A commonly asked question is if v.32 modems will work with v.42 -- and the answer is yes. If you asked the question "can I transmit ENGLISH over an FM RADIO FREQUENCY and have the listeners understand" the answer would be the same and for virtually the same reasons (here we're likening the v.42 method of packetizing data to ENGLISH and the v.32 method of modulation to FM RADIO TRANSMISSIONS). The v.42 and v.32 standards are for two completely different (but complimentary) areas of communication. In fact, you'll most likely discover that every v.32 modem you find has v.42, MNP or some other kind of error correction control built into it. So, combined together, a modem with v.32bis, with its higher transmission speeds, and v.42bis, with its greater compression ability, can be very fast when transmitting and receiving data. For example, a v.32 modem's raw throughput at 9600 bps would deliver 960 cps. Adding v.42 brings you up to 1150 cps and if the data is compressible then with the compression capability of v.42bis you could see even greater speeds (2 to 4 times greater depending on the data being compressed). A v.32bis modem's raw throughput of 14400 bps delivers 1440 cps. Adding v.42 brings you to 1700 cps and with data compression, again, it is possible to achieve 2 to 4 times that speed depending on the compressibility of the data being transferred. What exactly is the benefit of MNP? Three things (and I'll discuss both MNP -and- v.42 since they have the same benefits and the same reasons for being): 1) MNP (or v.42) provides you with an ERROR CORRECTED session between your modem and the modem at the other end of the phone line. If you have ever logged onto a system and found that you could barely read or write messages due to all of the line noise .. then you can appreciate the difference between a "clean line" and a "noisy line". When both modems have MNP (or v.42) then they are capable of filtering out the line noise. BUT, make no mistake about it - the line noise may STILL be there .. it just does not get printed on your screen nor the host screen because the modems have filtered it out. This "filtering process" is similar to the error correction protocols such as Xmodem or Ymodem. They send a block of data and a CRC together and if the receiving modem finds a different CRC value then the two modems resend the data until it is corrected. So, in the same manner that a file transfered with Ymodem is pretty much guaranteed to be "correct" after it arrives (even though line noise may have caused several re-sends of the data) the same is true of data that you see on your screen when using error correcting modems. 2) The second benefit of MNP (or v.42) is that while it is creating data packets for the "error correction protocol" it is able to reduce the size of the data by stripping out start and stop bits. For instance, a normal character takes up 8 bits plus 1 start bit and 1 stop bit for a total of 10 bits. On that basis you can figure that a 2400 bits per second modem will give you a maximum throughput of 240 characters per second (because each character is 10 bits long). The MNP (or v.42) protocol can strip the start and stop bits which subtracts 20% of the data and gives you a 20% increase in speed (minus a few percentage points for the protocol overhead). Therefore, without even compressing the data you can expect to see as much as 270 characters per second on a 2400 BPS line (versus the "norm" of about 235 cps on the same line). 3) The third benefit of MNP (or v.42) is DATA COMPRESSION. In the BBS world you are probably aware of files that are ARC'ed or ZIP'ed. The reason for using ARC or ZIP is to decrease the size of the file before storing it on disk - and then uncompress the file when you want to use it. This saves disk storage. When performing file transfers it also saves time! The data compression capabilities of MNP and v.42 are not nearly as good as either ARC or ZIP. But on straight ASCII text they are still capable of decreasing the data to about 50% of its size. Decreasing by 50% means that you can DOUBLE the throughput on the line so that a 2400 bps modem can effectively transmit 480 cps (the speed of a 4800 bps modem!). Now the drawbacks...... 1) You only get the benefits of MNP (or v.42) if the modem at the OTHER END also has MNP (or v.42) built into it. 2) Data Compression between modems is only effective if the data being transferred is NOT ALREADY COMPRESSED. This means that you can expect to see fast transfers on ascii text files - but transferring a file that is already compressed (such as an ARC or ZIP file) will actually be SLOWER than if the modems did not perform any data compression. Unfortunately, in the BBS world compressed data is more common than non-compressed data. Sure, you'll be able to read messages faster (if you can move your eyes that fast!) and you can download bulletins and other non-compressed data faster. But downloads of most files on BBS's will actually be slower. Fortunately, you can usually tell your modem to turn data compression off (prior to making the phone call) so as not to slow down your file transfers. Why are my file transfers slow? ------------------------------- The above question is one that just doesn't seem to want to go away. It is most often asked by users who have just recently purchased a high speed modem but even the veterans with high speed modems sometimes ask the same question. Let's look at a few possible reasons: Line Noise at Connect Time -------------------------- If line noise occurs during the connection process where your modem and the host modem perform their handshaking sequence looking for common ground then it is very likely that the two modems will agree to a SLOWER speed to avoid having problems during the remainder of the connection. For instance, we very commonly have users with US Robotics HST or HST Dual Standard modems complain that their modems are capable of 1700 cps but they are seeing only 1400 cps or maybe 1150 cps or even lower and they ask why. Let me explain: the HST modem has real BPS rates of 14400, 12000 and 9600. With the effects of MNP or v.42 (no compression here) you can figure about a 20% speed increase making the CPS rates 1700, 1400 and 1150 respectively. That makes it very obvious then that during the connection phase the modems agreed to only 12000 or 9600 bps instead of the full rated speed of 14400bps. In fact, if line noise occurs during the call the modems may very well decide to shift down at that time as well. If 9600 bps is noisy your modem may shift down even further to 7200 or 4800 bps. For the USR HST user you can, immediately after logging off, type ATI6 and your modem will tell you what your connect speed was which may help you determine if the slow down was the speed of the connection. Other modems have similar drop down capabilities. Line Noise During the File Transfer ----------------------------------- For years people used to state that 2400 bps was as fast as DIAL UP phone lines could handle and that we would never go beyond that rate due to the low bandwidth and high noise levels of telephone lines. Then comes along people like US Robotics and Hayes and many others who make high speed modems practical even on dial up lines. Well, line noise is NOT a thing of the past, lost and forgotten. It is still with us. These new modems are not magic either. They manage to HIDE the line noise and in some cases are able to filter it out or even through special encoding cancel some of the line noise. But it is still there. When line noise occurs during a file transfer between two modems which have established an error correction session the only TANGIBLE EVIDENCE of this line noise may very well be SLOW FILE TRANSFERS and nothing else. The USR HST modem has a light on the front panel labelled ARQ. Depending on which modem may have to recover from the line noise by re-sending its data you may see the ARQ light flash perhaps randomly, sometimes very quickly to indicate that it is having to retransmit the data. Most modems give no indication at all that extra work is being required of the modem. Some modems eventually give up and just drop the carrier completely. Like the first example above the HST's ATI6 report (after hanging up) can give you information as to how many times packets of data had to be retransmitted which may give you some clue as to how noisy the line may have been. Inability to Compress ZIP Files ------------------------------- If you find that downloading ASCII files produces OUTSTANDING file transfers but that downloading ZIP files cuts file transfer CPS rates 25% or more off of your expected throughput then very likely you have turned on what is called "data compression". If you've ever tried to use PKZIP to zip a .ZIP file you usually find that PKZIP will decide to just "store" the file rather than "shrink" or "implode" the file. Why? Because in its attempt to shrink the file it actually causes the file to GROW in size! Quite the opposite of the desired effect. The same exact thing happens when you try to use your modem's built-in data compression capability on a file that is already compressed. The modem's compression algorithm actually causes the data to GROW (i.e. it sends more bytes out over the phone line than are coming into the modem) which slows the file transfer. PCBoard's modem configuration program, called PCBModem, is generally set up to turn data compression ON by default! Why? You ask... because it is generally believed that it should be up to the CALLER to decide if he wants to take advantage of the data compression capabilities of his modem. If PCBModem were to turn data compression OFF then *nobody* calling your system would get data compression. Leaving it enabled allows the caller to make the choice. However, many sysops like to use the same high speed modem that they set up for use with PCBoard to dial out to other systems. What they are forgetting is that PCBModem has turned data compression ON and they go right ahead and try to download a ZIP file. Our recommendation is this: Leave data compression turned on when the BBS is up and running but turn data compression off when dialing out (assuming you are planning to download ZIP files). One "high tech" solution to the problem is to upgrade your modem to the v.42bis standard. In theory, like PKZIP, v.42bis data compression will detect when it is making the data grow and turn itself off so that the data is sent out un-compressed (similar to PKZIP's simple "storing" of zip files). Again, in theory, that means that you can leave data compression turned on all the time and never have to worry about slow transfers of pre-compressed files. Flow Control Problems --------------------- For high speed file transfers to work you generally want to open your port speed (the speed that your PC talks to your Modem) at a rate that is faster than the line speed (the speed that your Modem talks to the other Modem). This is somewhat akin to squeezing a bottle to make the liquid come out faster than if you just poured it out directly. If the data is sent to the modem at 9600 bps then the fastest over-the-phone-line rate will be 9600 bps. By sending data to the modem faster than the over-the-line rate you give the modem time to work on packetizing the data (this is where the 20% increase in speed comes from) and possibly even compressing the data (if compression is turned on and the data is not already compressed). The only trouble is, if you are sending data to the modem FASTER than it can send it across the line then there are times when the PC simply must stop sending and wait for the modem to catch up. That is when a traffic light called CTS and RTS, must enter the picture to control the flow of the data. To indicate when the modem's buffer is sufficiently empty to receive data and to indicate when it is full and the data flow must be stopped. If your modem is not configured correctly for flow control, or if your software is not configured correctly to use flow control, or if your asynch board does not support flow control, or if your modem's cable does not have the CTS and RTS lines wired properly ... all of these possibilities can result in flow control errors which will cause data to be lost. When data is lost due to flow control problems there is only one solution and that is to send the data again! This results in slowing down your file transfer. Zmodem will give a ZRPOS error (which means resend the last block of data) while other protocols will simple indicate an error and expect a retransmission of the data. Full flow protocols such as Ymodem/G and 1K-Xmodem/G have no built-in facility to request that data be re-sent and therefore must CANCEL the entire file transfer if such a loss of data occurs. Similar to the modem's buffer and its traffic light to control the flow of data, your PC, and the SOFTWARE it is using, will set up its own local buffer to receive data from the modem. If you are multitasking on your PC you may be asking the PC to perform other tasks besides attending to the data coming in from the modem. If the modem's buffer (or even the buffer on your asynch card) gets too full and is not emptied quickly enough the data can be lost. Your software should be configured to use flow control to tell the modem when to stop sending data to it. Another course of action is to utilize the National Semi-conductor NS16550AFN uart chip in your asynch port which has a 16-byte buffer on it (that may sound small but it is 16 TIMES the size of the buffer used by all uart chips before it). All things must come together to work in harmony, your modem, your software, your asynch card and cable. And this is only on one side of the connection. The same requirements are necessary on the other side of the telephone line to ensure fast and reliable transmission of data. File Transfer Protocols ----------------------- One more area that people need to learn about is choosing the right protocol for the file transfer. Too often you'll find people using Xmodem to download files when their modems have established a high speed connection. What's wrong with Xmodem, you ask? Xmodem sends packets of 128 bytes of data and after each and every packet is sent it waits for the receiver to tell if it the packet was good or bad. This is fine at slower speeds because if it takes 1/10th of a second to receive this acknowledgement at 1200 bps then at most you've lost the ability to send 12 characters out the port. At 2400 bps that same 1/10th second delay means a slow down of 24 characters. And at 9600 cps the delay means 96 characters. And a 1/10th of a second delay is being OPTIMISTIC here because if you are dialing long distance or going over a satellite or using a packet-switch network the delays might actually be measured in full seconds. Ymodem sends packets of 1024 bytes. This means that the same delay that Xmodem experiences occurs only 1/8th as often because it sends 8 times as much data before waiting for an acknowledgement. Okay, that means that Ymodem will give you faster file transfers than Xmodem. But it still is not perfect. Zmodem, on the other hand, does not wait for an acknowledgement but instead continually sends data until the receiving end tells it to back up to a previous location (ZRPOS) in the data stream and resend that information. Since there are no built-in delays every X-bytes of data you'll find Zmodem gives you excellent file transfer rates. Ymodem/G, having less over-head than Zmodem because it ASSUMES that your modem is configured correctly and that there will be no data loss, is able to send the data even faster than Zmodem. The one caveat: if an error *does* occur then the file transfer must be aborted. In summary ---------- With the above arsenal of information, about line noise, about data compression, about flow control and about file transfer protocols you should have enough information to guide you to the real cause of the slow down in file transfers. There is no "one set answer" to the question. But taken together the above should help you determine which answer, or answers, may apply to your specific situation. One final point: Make sure the software you use is top-notch. PCBoard for the host connection has been tested to give very fast and very reliable transfers all the way up to 115K bps. On the caller's side programs such as Qmodem, Telix and Procomm are all worthy of evaluation. (note: the US Robotics HST was mentioned in the above, not to pick on HST for line noise, but simply because a very large majority of PCBoard sysops use HST's and can identify with the examples given) ZMODEM File Transfer Protocol ┌ X │░░░░░░░░░░░ 1200 ├ Y │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ └ G │▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ These represent "best case" └───────────────────── transfer rates for Xmodem, 20 40 60 80 100 120 (CPS) Ymodem, and Ymodem-G. ┌ X │░░░░░░░░░░░ Zmodem transfer rates will 2400 ├ Y │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ be somewhere between Ymodem └ G │▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ and Imodem/Ymodem-G but the └───────────────────── integrity of the file will 140 160 180 200 220 (CPS) be much greater due to 32- bit CRC error checking, as ┌ X │░░░░░ explained below. 9600 ├ Y │▒▒▒▒▒▒▒▒▒▒▒▒ └ G │▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ └────────────────────────────── 500 600 700 800 900 1000 1100 (CPS) NOTE: Transfers made within a packet-switched network, like PC Pursuit, will result in additional errors and transfer time. What is ZMODEM? It's a relatively new file transfer protocol by Chuck Forsberg, creator of YMODEM, which is very powerful, and remedies many of the defects in X/Ymodem transfers. A sliding-windows type protocol, ZMODEM handles delays induced by packet-switched networks like PC-Pursuit or by phone line problems caused by microwave relays, satellites, etc. And... ZMODEM is a robust protocol that will survive noisy lines where other protocols may fail. It also uses 32-bit CRC for error- checking, even further reducing the chances of an undetected error during a transfer, thus making it more reliable than even WXModem, SeaLINK, or sliding windows Kermit. With ZMODEM, you can resume an aborted download right where you left off! How many times have you started downloading a file and it aborted after receiving 95K out of 100K? A little dis- concerting, to say the least. Well, with Zmodem, by adding the "-r" parameter at the end of your receive command line, you can restart the download WHERE YOU LEFT OFF!! During a Zmodem transfer, you will notice that your modem lights do not flicker between transmitting and receiving (ACK/NAKing as in X/Ymodem) unless an error occurs. The data is being sent in a continuous stream, similar in nature to MNP protocols (Ymodem-G and Imodem), but without the need for MNP error correcting modems. Here's what you will need to do to use ZMODEM: ∙ If you are using one of Chuck Forsberg's own comm programs (Pro-YAM or its shareware counterpart ZCOMM), you are all set, needing only to issue "sz filename.ext" to upload, and "rz" to download (no filename is required to receive). ∙ If you are using any other communications program, you need a copy of Chuck Forsberg's DSZ.COM program (always avail- able here with the syntax "DSZmmdd.ZIP", where "m" is the month, and "dd" is the day of the version's release -- for example, DSZ0216.ZIP is available, as of this writing, and was released 02/16/89). DSZ is a sub-routine that can be run from within other comm programs to perform ZMODEM transfers (supports Xmodem/Ymodem/Ymodem-batch/Ymodem-G/ YmodemG-batch/Zmodem, etc. as well). What is the 16550 and how can it benefit communications? -------------------------------------------------------- The chip, formally known as the NS16550AFN chip, is the heart of your asynch board. It is the UART chip, or Universal Asynchronous Receiver/ Transmitter. The advantage of the 16550 over the older 16450 and 8250 UARTs is that it has a 16 byte buffer on it. Now, sixteen bytes doesn't sound like a whole heck of a lot but it is SIXTEEN TIMES the size of the buffer on the older UARTs which only had one a one byte buffer. The advantages of the 16-byte buffer are two fold: 1) It makes high speed communications more reliable. On the older chips, with their one-byte-buffer, you would lose data if a second byte came in from the modem before the CPU had a chance to pull the first byte out. The 16550, with its 16-byte-buffer, gives the CPU up to 16 chances to pull the data out before a character is lost. To realize what this means you can figure that at 19200 bps you are expecting the CPU to service the comm port 1920 times each second or once every .0005 seconds. If the CPU happens to take .0006 seconds to get around to servicing the comm port then in a one-byte buffer UART that first byte is lost. On the 16550 chip, with 16 bytes of buffer space, you have up to .008 seconds to service the comm port. 2) It helps make a multitasking system more efficient. When PCBoard is transmitting data it has to stop the CPU and fill the UART's transmitter buffer. That means that if the caller in the background is doing a directory scan his scan will take longer while PCBoard attempts to send data out to the first caller. In the one-byte-buffer UARTs at 19200 bps PCBoard must stop the CPU 1920 times each second just to send data out the comm port. With the 16550, however, it can stuff up to 16 bytes into the buffer at a time and therefore interrupts the CPU only 120 times each second. That drops the performance hit on the CPU, even at high speeds, to almost that of a 1200 to 2400 bps modem! To top it off... the older 8250 chips were buggy, making them less reliable, and they were never designed for the high speeds that we expect out of our modems today. The NS16550AFN, on the other hand, is designed with high bus speeds and high modem speeds in mind. When multitasking, even at slower baud rates, the 16550 can be very helpful in providing smooth operation for the entire system. NOTHING PUTS THE 14,400 SPEED OF V.32 BIS TO WORK FOR YOU LIKE A COURIER V.32 BIS WITH ASL! With a Courier V.32 bis modem, you can transmit at 14,400 bps, full duplex - that is both directions simultaneously. With V.42bis data compression, throughput can reach 38,400 bps. Throughput on a typical text file is about 35,000 bps. That's almost 50% faster than any 9600 bps modem on the market. And 15 times faster than a 2400 bps modem without MNP. And a Courier makes optimum use of that speed. Only a high speed Courier gives you ASL -Adaptive Speed Leveling. Modems have to slow down for noise. But when two courier V.32 bis modems are working together, they continue to monitor the line and speed up again the moment conditions improve. All other modems leave you in "low" for the remainder of the transmission. That can turn a one minute call into 5 or 10 minute call. Two Courier V.32 bis modems don't have to stop and then resynchronize every time they switch speeds either. There are none of those irritating pauses when you're at the keyboard. Two courier V.32 bis modems train up in 3 or 4 seconds, instead of the typical 15. In polling applications, that can add up to significant savings. The Courier V.32 bis modem uses powerful Intel 80188 microprocessors. Even with all the calculations involved in V.42 bis error correction and data compression, it has the power to transmit simultaneously in both directions at 14,400 bps. A modem using the slower Z80s or 8031s can't handle that kind of load. You're not getting what you paid for. If you need compatibility with V.32 and V.32 bis modems from a variety of makers, the Courier V.32 bis has it. If you need international compatibility, the Courier V.32 bis gives it to you. The Courier V.32 bis puts you in high speed asynchronous communication with the wide world of PC's, minis, and terminals. And you get the synchronous communication you need for mainframes. Because it's full duplex, its also ideal for host-to- host communications or bridging LANs. With a Courier V.32 bis modem, you're not just getting high speed, You're getting high performance.