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. Such as the Prometheus ProModem. One of the more reliable modems released on the market some 2 1/2 yrs ago. This modem is 100% v.32 compatable. Which means it will connect (communicate) with "ANY v.32 modem." Well worth the $'s spent. 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 simple advantages 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. What is v.32? What's the difference between it and v.42? 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. 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. It also includes the ability to compress data on the fly to enable higher throughput without requiring a different modem modulation scheme. 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. A commonly asked question is if v.32 modems will work with v.42 -- and the answer is yes and no. If you asked the question "can I transmit an FM RADIO FREQUENCY and have the listeners understand" the answer would be the same and for virtually the same reasons (comparing the v.42 method of packetizing data to English and the v.32 method of modulation to FM). 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... a v.32 modem can talk to a v.42 modem -- if the modem on the other end is a v.32 modem and if it can understand the v.42 method of packetizing data (or the MNP method since MNP is included in the v.42 standard). What is the benefits of MNP? 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. 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). 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...... 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. 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. 1 9 2 0 0 B P S O P E R A T I O N --------------------------------------- December 27, 1990 We receive a number of comments concerning RBBS-PC operation and the use of 9600/19200 bps modems. In order to clarify a few items, the following should help in properly configuring your system and in explaining high speed modem operation to your callers (and yourself!). First, some basics. When a user calls a BBS system, there are generally 3 links between the two machines which are speed related. The first is the speed or bps rate at which the caller's CPU is connected to their modem, the second is the link between the two modems themselves, and the third is the link between the host modem and the host CPU. For simplification, we will refer to these three speeds in the remainder of this document as CLink (caller CPU to caller modem), MLink (modem to modem), and Hlink (host CPU to host modem). A simple diagram might help here: -------- -------- ------- ------- Caller's Caller's Host Host CPU Modem Modem CPU -------- -------- ------- ------- |___ CLink ___| |___ MLink ___| |___ HLink ___| RS-232 Cable Telephone Line RS-232 Cable (DTE Link) (DCE Link) (DTE Link) Second, CPS is now used extensively by various communication's programs in order that a caller can judge their throughput "performance" during a file transfer. For the benefit of those who do not understand bps rates and CPS, here is a very basic outline. Generally, a byte of data (one character) is sent as a start bit, followed by the actual character, followed by a stop bit. When running at 7,E,1, the highest character which can be sent is a chr$(127). However, that means you can not send any "binary" files which usually contain many characters from chr$(128) to chr$(255). However, when using 8,N,1 settings, any of these "high order" characters can be transmitted - which not only allows for the transmission of binary files, but also allows for the use of "graphics" display files which are comprised of many of these high order characters. Now, if we add the start bit, plus the 8 bit character length, plus the stop bit, we end up with 10 bits needed to send one character (or a single byte of data) to the other machine. At 1200 bps, (1200 bits per second), if we divide the bps rate by 10 (the number of bits per byte), we end up with a maximum throughput rate of 120 characters per second (or 120 bytes per second if you will). Similarly, at 2400 bps, the theoretical maximum rate would be 240 characters per second. That is why when doing an ASCII file transfer, CPS rates equal to bps rate/10 can be achieved. However, when doing protocol transfers, the time delay blocks, as well as block "error checking" bytes which are added to chunks of data, end up cutting down the actual throughput rate of the given file so that something in the order of 85% effective rate is achieved. So, how do some of the new modems do BETTER than the bps rate/10? Simply, they "compress" the data to be sent using compression algorithms similar to those used when ARC'ing a file - so that they can send more bytes of the file at one time. Of course, the modem on the opposite end must be able to "un- compress" the data - or the whole thing falls apart! Also, since the modems themselves are handling all error checking, there is no need for the software to control the sending of blocks and "waits" for an good acknowledgement. All it (the software) needs to do is send the file out to the other end - monitoring RTS/CTS flow control in the process. What all this ends up doing is allowing some of the new high speed modems to produce CPS throughput rates of 1100 to 1600 CPS or higher under ideal conditions - including "clean" lines, maximum "horsepower" CPU's and hard disks, etc. Third, we need to mention a little bit about flow control. Generally speaking, there are two types of flow control - XON/XOFF and CTS/RTS checking. XON/XOFF is the "standard" flow control which has been used for years in async communications. It is done by having one CPU send the other CPU's software a signal to start or stop transmitting data. This works great at baud rates up to about 4800 baud, as long as there is a "buffer" of adequate size on both machines, and the two softwares "look for" fairly frequently during ALL of their processes. If they do not check for the appropriate signal often enough, and their communication's buffer is not large enough, one machine can keep sending data to the other - even though the other is not ready to receive it - causing a loss of data. Most programs on the market today monitor XON/XOFF checking very well, and have no problems with flow control at the lower speeds. However, when operating at rates of 9600 bps and above, data can be sent back and forth so quickly, a quicker and more reliable method of controlling the flow of data must be implemented. Here we use RTS/CTS (Ready to Send/Clear to Send) flow control. What happens is that in effect, hardware bits are toggled to immediately trigger the necessary start/stop sequences to prevent data over-runs. Although the two software programs must continually monitor the CTS/RTS bits, it can usually be done much more quickly and effectively than having to check for the XON/XOFF software signals. Now, we know there are three links between the two machines, and that there must be good flow control in order to prevent data loss. What some don't realize is that EACH link can run under it's own flow control! In other words, the CLink must have proper flow control, the MLink as well, and of course the HLink too. If you consider that the caller may only be using XON/XOFF flow control for the CLink portion, while the host CPU is trying to only use RTS/CTS flow control for the HLink, and the two modems are using neither, you can imagine the problems that may develop in trying data from being lost or corrupted! So, how do we as sysops figure out how to set up our "host" modems and HLinks, plus, how do we educate our caller's to properly set up their hardware and software links? Unfortunately, with the large variations in current 9600 baud modem technology and configuration settings - that can be VERY difficult. But, let's take it a step at time in general terms. First, let's tackle the host side. When hooking up a 9600 bps modem on your host CPU, you need to determine your HLink speed of operation and type of flow control. If you are running on a "slow" machine, or under some sort of multi-tasking software where the hardware may not be able to keep up with full 19200 bps flow, you will have to limit yourself to a maximum rate of 9600 bps or lower in order to insure reliable operations. However, if your hardware can support a full 19200 bps HLink, then you need to change some of your modem settings vs the sysop who will be using 9600 bps as their HLink speed. Why? Because of the way RBBS-PC operates. If the opening speed of the modem is 9600 bps or lower, RBBS-PC has been written to allow the HLink to AutoBaud to match the speed of the MLink. However, if the opening speed is 19200, RBBS-PC assumes that the sysop wants to "lock-in" the maximum throughput rate, and does NOT AutoBaud the HLink to try and match the MLink (with the exception of the Hayes 9600 V- Series modem. See note at end of document)! So, how do we make adjustments in the modem settings? First, a word about AutoBauding and what happens. AutoBauding is simply a term to describe the ability of the host software to change the speed of the HLink to match that of the MLink. Here's how it works. A caller sits down to their machine. They decide to call XYZ board across town. They are using an ACME 1200 bps modem. XYZ BBS across town is using a GENERIC 2400 bps external modem - which the sysop has set up with an initial port opening speed of 2400 bps. XYZ sysop brings his/her board up on-line. RBBS-PC opens the com port at 2400 bps (the async card is now set to operate at 2400 bps). Likewise, the modem at XYZ board also responds at 2400 to the initial commands and is ready to answer the phone. The caller dials XYZ board, and the board gets a ring detect. At that time, RBBS-PC sends the modem an "ATA" command to answer the phone. This is done of course at 2400 bps. The modem goes into auto-answer mode and starts it's initial handshaking with the caller's modem. First, it tries to establish a good connection at 2400 bps. Since it fails, it drops down to 1200 bps and tries again. Success! The modem-to-modem link (MLink) is now at 1200 bps. The modem now sends a "CONNECT xxxx" message to the host CPU via the HLink at 2400 bps. The host software looks over the response and is told that the connection was made at 1200 bps and not 2400 bps. Since the connect message is the LAST command the modem will send to the host via the HLink at 2400 bps, the host CPU must automatically drop down to 1200 bps, or all future data transfers on the HLink will be garbage. So, the host software in this case), immediately adjusts the async card's bps rate divisor "latches" on the fly - so that the HLink is now at the same speed as the MLink - which is of course also the same speed as the CLink. Now that all the links are "talking" at the same speed, data starts to flow normally between the two machines. One exception here. RBBS-PC of course expects the caller to be at 8,N,1 modem settings. If the call is not at the proper settings, it recognizes the fact and sends the caller the message indicating they should switch to 8,N,1 before trying their call again. Now, all of this works fine if the host modem is able to quickly change speeds to match the caller, and it properly returns the correct "CONNECT xxxx" message to RBBS-PC. The older 300/1200/2400 bps modems usually have no problems with this. However, enter the world of 9600 bps modems - where there is yet no "standard" among the various manufacturers on how the MLink should be established! Plus, based on the firmware in the modem itself, some may have a great deal of trouble in dropping down from the higher speeds to the lower speeds in an attempt to establish a good carrier (MLink) with the caller. And, since the sysop has the option of either allowing the HLink to stay at a fixed rate or to AutoBaud to match the MLink, things start to get a little messy. So, what does the sysop do to properly configure their system if they want to run one of the new 9600 bps modems? First, they must of course decide upon the brand of modem they will use. Since each of the 9600 bps modems use a different technique for handling full duplex operations (i.e. the ability of the caller to see on their screen the character they typed in a reasonable amount of time), the sysop must be careful to purchase a modem which will meet their needs in "interactive throughput". Since some 9600 bps modems are not actually operating in a full async mode (i.e. they are simulating what normally happens at bps rates of 2400 and below in the modem's ability to send and receive data at the same time), there can be long delays between when the caller presses a key on their keyboard and when they see the character on their screen. This is very annoying and also usually means file transfer throughput rates may be affected in a similar manner. Second, they must consider how well the modem will work in day-to-day operations in handling the ability to establish a good carrier with the caller - regardless of the speed of the HLink and the quality of the line. Third, the sysop should consider how easy it will be to configure the modem to operate reliably. If it requires the sysop to have a PhD in figuring out the modem manual and the all the various combinations of settings, you may want to check out a different brand of modem! So, a modem is finally selected and is ready to be installed. Now, we get back to the question of what speed are we going to set up the HLink at - since IT determines how the host modem should be configured! If it is decided that the HLink is going to be 19200 bps (the host hardware can safely handle full 19200 bps operations), the sysop needs to set up the Comm port so that the HLink ALWAYS stays at 19200 - since that is what RBBS-PC is going to do! If 9600 bps is the highest speed which will specified, then the modem MUST be configured to allow for AutoBauding to occur (See Hayes 9600 V-Series modem note at end of document). In either case however, the sysop MUST enable RTS/CTS flow control!! At this point, the sysop should check their manual for the appropriate modem setting to accomplish the above. Note that the manual will probably indicate not only a "send" flow control parameter, but a "receive" one as well. In that case, all should be set to allow for CTS/RTS flow control! CAUTION: IF YOU ARE GOING TO BE RUNNING AT EITHER 9600 OR 19200 Bps, AND YOU DISABLE RTS/CTS FLOW CONTROL WHEN CONFIGURING THE HOST MODEM, NEITHER IMODEM OR YMODEM-G PROTOCOL TRANSFERS WILL WORK RELIABLY - SINCE DATA OVER-RUNS ARE SURE TO OCCUR!!! Also, some modems which use MNP error checking, allow the modem to either "look for" another MNP modem, or to ignore the fact that there may be another MNP modem calling in. Since the time to "look for" another MNP modem can take up to 6 seconds, the sysop should be aware that their caller's may get a delay between the time the phone answers the caller and when the "Connection Established" message is sent. Likewise, if the caller has "look for another MNP modem" enabled on their end, while the host modem DOES NOT, the host may send the "Connection Established" message to the caller - but since the caller's modem is still trying to look for another MNP modem, the initial data will be lost to the caller and will NOT appear on their screen. This becomes very confusing for not only the caller, but the sysop as well in trying to figure out why some callers are loosing the initial logon message, while others receive it fine. Unfortunately, the only answer to all of this is education on the part of the callers as well as the sysops. They both need to have an understanding of high speed communications and the various modem's characteristics if they want to enter the high speed arena. It is no longer simply a matter of plugging in a modem, setting a few switches, giving the modem a few simple commands, followed by totally reliable unattended operation. If all/any of the above makes sense, the next question usually asked by the sysop is "Gee, where do I find out about all this stuff and still - no one has told me how to set up my modem!" Unfortunately, there are very few single sources of information on how all of the various brands of new 9600 bps modems operate - including the various commands needed to properly configure them for both the caller as well as the sysop. For example, the US Robotics Courier HST modem, when operating at 9600 bps, uses a USR proprietary means of communication. However, at 1200/2400 bps, it can be configured to "talk" to other MNP based modems! So, the sysop must be able to relate 1200/2400 bps MNP settings to other MNP modems, while considering USR settings for 9600 bps and above. What all this boils down to is that RBBS-PC SysOps are frequently asked if we can provide the necessary settings for the various 9600 bps and other modems which will allow all of this to work properly. At present, the answer unfortunately is no. We have neither the time or resources to become thoroughly knowledgeable on all of the various brands of 9.6 modems in order that they can be properly configured under the following settings: 1. Callers who want their CLink to be at a fixed rate 2. Callers who want their CLink to auto-bps 3. Sysops who want their HLink to be at a fixed rate 4. Sysops who want their HLink to auto-bps As can be seen, multiplying the above by the number of 9600 bps modems on the market, and then compounding this effort with the fact that there are currently a lot of ROM changes (hence modem setting changes) going on in the industry - it is virtually impossible for any one source to remain current on everything associated with 19200 bps. Therefore, possibly the best source of information, and obviously most current, should be the modem manufacturer themselves. Hopefully, they will be fairly familiar with the software that is being used at both ends of the connection to provide sufficient information on the proper modem settings to use under those conditions. However, we do use a default modem setup program, that we use to configure modems tested on this system for operation. We have found that when using the settings in the RBBS-PC program, we are able to successfully operate the Hayes 2400, Hayes 9600 V-Series, US Robotics Courier HST, Microcom AX9624C and Prometheus ProModem modems with the 17.3 version software, with some minor updates from modem manufactures and (Alot of old fashioned guesswork!) Here are a few other bits and pieces of information concerning 9600/19200 bps operation that are frequently discussed: Question: "Why is it that on the local (host) screen, it appears that the caller is using XON/XOFF flow control when operating the host at 19,200 bps?" Answer: What is usually happening here is that the host modem may have an internal buffer to store up to 8K of data it receives from the host CPU via the HLink. It then funnels the data out to the caller at the MLink speed. So, what the sysop usually sees on the host side is a little blip of data going to the modem as almost an entire screen of data is sent to the host modem and buffered there. Then, the host modem dribbles out the data to the caller at the MLink speed. No lights are usually present on the host modem to indicate that the data is actually being sent to the caller - since the TD or SD (transmit data or send data) light ONLY flashes when the host CPU sends data to the host modem via the HLink - NOT when the host modem is sending to the caller's modem via the MLink. What this ends up looking like is 3/4 of a screen display appearing almost instantaneously on the host, followed by a delay, followed by another quick screen display, followed by a delay. This is normal, and you have to remember that the caller is simply seeing what they always do at the speed at which they are connected - rather than at 19200 bps. The pauses are caused by having properly defined your CTS/RTS flow control parms - since when the host modem's buffer is full, it signals (by toggling the RTS/CTS signals), the fact that the host CPU should delay sending it (the host modem), and more data until it has had a chance to empty out it's internal buffer to the caller. Question: "My callers are complaining that since installing a 9600 bps modem and running it at 19200 on the HLink, they are no longer able to (Ctrl-K) abort a "non-stop" listing, or are unable to interrupt a long message display. What's wrong with my settings or the software?" Answer: Nothing is wrong with either of them! Your callers are simply trying to perform functions against the internal buffer of the host modem - over which you and/or the software may have no control. When operating the host at 19200 as indicated above, a whole screen of data can be sent to the modem in a second. There it will be buffered until it is sent to the caller at the speed at which they can accept it. So, for example a complete message can be sent to the host modem - after which the host pauses awaiting the caller's response to a "More" prompt. In the meantime, the caller is just barely starting to have the message displayed on their local screen. They decide they want to (Ctrl-K) abort it. So, they press (Ctrl-K). Since the host has already sent all the data is going to, and the host modem will not recognize the (Ctrl-K) as a signal to flush out what is in it's buffer, the caller continues to receive the data from the host modem until it's buffer is empty. The slower the MLink speed, the worse this situation will be. If your caller's software supports the sending of a BREAK signal to your modem, and your modem supports the "dumping of it's buffer upon receipt of a BREAK signal, this delay can be defeated. Question: "If this is the case above, why not let me define the host modem's buffer size?" Answer: That is between you and the modem manufacturer and the various settings they allow. However, decreasing the internal buffer size of the host modem may degrade the modem's ability to operate up to it's advertised speed. Question: "On my system, the best download CPS rate that any of my callers get when using my new GENERIC 9600 bps modem is 700 cps. But, on my friends system down the street, I see his caller's getting over 1000 cps all the time! What am I doing wrong?" Answer: Possibly nothing! Some of the things that can cut cps figure down VERY quickly are: 1)CPU speed, 2)multitasking the host CPU, 3)speed of the host hard disk, 4)line quality, 5)modem settings, etc. Any of the above can make subtle differences in your caller's CPS throughput. Remember, at 9600 bps, an increase of 1 second in the time it takes to send a given piece of information can have dramatic effects on throughput rates - since ideally 1 second will cause a "loss in effectiveness" of approximately 1000 bytes! Question: "Should I buy a 9600 bps modem, and which one should I buy?" Answer: Sorry, but that question can only be answered by you after determining your needs, the needs of your callers, and what you feel you can afford. Remember, at present there are very few if any "standards" among the 9600 bps modem manufacturers - which normally means only "like manufactured" modems can talk to each other at 9600 bps. So, if you decide to buy one, only callers who have the same brand of modem will be able to take advantage of your "new technology". Second, your users will have a tendency to look to you for leadership in what modem they should buy so that they can talk to your system at the higher rates of speed. If you recommend they go out and by an ACME 9600 bps modem for $1,000, and 3 months from now the GENERIC 9600 modem at $595 becomes the defacto "standard" which everyone else is buying and running, your caller's will be understandably a little upset with you for influencing their buying decision in the wrong direction. You are assuming a lot of responsibility as a BBS SysOp when you bring a system up on-line. Callers will expect that you are a leader in the area because of your choice of software. Be prepared to live up to their expectations. Question: "Why is there a delay between what the caller types at their keyboard and what they see on their screen?" Answer: At 2400 bps and below, the modem(s) can send and receive data at the same time. Therefore, the "turnaround" time, (the time it takes the caller to send the keystroke to the host, and for the host to send it back to the caller for display on their screen) is very short - measured in fractions of a second. However, at 9600 bps, most modems are not operating in "true" async mode with instantaneous turnaround. Instead, they are "simulating" async operations - since they are also providing full error checking of the data that is being sent and received. In order to do this, several schemes can be used. However, the end result is that at 9600 bps and above (under current technology), turnaround time may be higher at 9600 bps than it would be if the caller were at 2400 bps. Some modems are better than others. Some are very bad. You should check around to find one that will meet your expectations. A $400 9600 bps modem which is prone to errors and has terrible turnaround time is not a "bargain". Make sure you are getting what you paid for. Remember also, that just because you can buy a certain brand of modem cheaply does not mean your callers can automatically do the same. If your callers can't afford a modem which will talk to yours, your money has also been wasted. Question: "I am running under a network environment. What should I set my upload buffer size to be inside RBBS-PC to insure maximum throughput during uploads to my system?" Answer: That depends on the speed of your network, the speed of your hard disk, the type CPU's and UARTs you are using, and your over-all network activity. For most networks, although it may sound strange, you may get BETTER throughput during uploads if you set your buffer size to 4 or 8 blocks! Only if you are running in a true "standalone" environment with a fast and/or a very fast network (10 meg throughput) will a large buffer size usually benefit you or your callers. The reason being is that most networks will more efficiently handle a small packet transfer request on a more frequent basis than they will a large one - based on other network activity. The ability to define an "Upload Buffer" size in the RBBS-PC program can provide increased throughput to some systems - especially those running high speed modems. However, by defining a good size buffer, you are going to be allocating additional low memory for the buffer. This usually has minimal effect on a system running in standalone mode, or in a true network environment. However, if you are running under multitasking software, you may have problems if you try and define your upload buffer too large. You will run out of memory and get all sorts of strange error messages. The best recommendation we can provide is to start with a buffer size of 4 blocks and work up from there. If no strange errors occur, increase the number in 4 block increments. We suggest NOT exceeding 32 buffers max for a multitasking environment. Question: "My PC Pursuit callers are really griping about the new code and my new 9600 bps modem! Seems none of them can download anymore! What did you mess up in the new code?" Answer: Nothing! The routines used in 17.3 are the same as those used in previous versions. The problem centers around PC Pursuit and the communication's program they are using. What happens is if you are operating your HLink at 19200 and PC Pursuit is a little busy, the caller's communication's program may abort - since PC Pursuit is not geared up to handle the high rate flow of data being given it. To correct for the condition, have your caller's select "relaxed" protocol transfer type in their communication's program, install a Zmodem DOOR application, or drop your HLink down to 9600 bps. Additionally, some of the communications program they (your callers) are using are very sensitive to timing problems on their end. You can also suggest that they try a different communications program. In summary, folks purchasing one of the new 9600 bps error correcting modems hope the new modem will really make their system file transfers fly. Unfortunately, some will find that 19200 will not work on their system. The reasons are many, but basically boil down to what type UART(s) and CPU the system is using, what brand modem(s) the board is running, whether the sysop is running any software which must control the COM port buffer interrupts (this includes all multitasking software, etc.), and how the system intends on supporting PC Pursuit callers. Unfortunately, some multitasking software is unable to efficiently time slice concurrent 19200 bps operations on one or more partitions, causing device timeouts when the opposite partition attempts to output anything to it's respective COM port. RBBS-PC attempts to trap for as many of these timeout conditions as possible. However, in some cases, the multitasking software may NEVER "release" the opposite COM port, causing that node to effectively loose it's COM port. This has the effect of shutting down that node. Additionally, even if 19200 does work under your multitasker, you may find that file transfers are SLOWER than at a straight 9600 bps setting. The reason again is the way the interrupts are handled and the amount of timeout errors which are necessarily being trapped by the code. Basically, if you experience a large number of errors while trying to run one or more nodes at 19200 bps, you will have to set your modem open speed to a max of 9600 bps. Additionally, if the CPS throughput is less at 19200 that it was at 9600, you will likewise be best to set back your modem speed to 9600 max. Please note that the additional throughput gained by running the host modem in a locked 19200 bps setting is minimal compared to straight 9600 bps. Plus, the chances of getting a device timeout on another node is much less when running at 9600 rather than 19200. 19200 will work best for those folks running either true networking systems who have "tuned" their network for maximum throughput, or for those running 19200 in a single node standalone mode. We estimate 95% of all multitasker sysops will find that 9600 bps is the maximum speed they will be able to operate their nodes reliably. RBBS-PC DOOR operations at 19200 now also present a unique problem. After reading the above, it is easy to see why some DOOR application programs may have difficulty running under a 19200 bps configuration. If the DOOR program does not take into consideration the fact that at a modem opening speed of 19200 the HLink is to always remain at 19200, it can attempt to AutoBaud the HLink - totally messing up the pre-established links. The value in the DORINFO(X) file may indicate 2400 bps, which would be the speed at which the MLink was established. However, if the sysop has opened their host computer at 19200, that 2400 value should then be used for informational purposes only! The DOOR application should therefore check BOTH the CALLERS file as well as the DORINFO(X) file in order to gain ALL the information needed to properly handle their application. Hayes 9600 V-Series Notes ------------------------- RBBS-PC 17.3 fully supports the new Hayes 9600 V-Series modem at all speeds - including 19200, 9600 and lower bps rates. However, since the Hayes 9600 V- Series operates entirely different than the other current 9.6 modems on the market, it is essential you understand the difference if you intend on using a Hayes in your operation. Most of the new 9.6 modems allow setting the HLink to a fixed speed of operation - regardless of the speed of the caller. However, the Hayes V-Series does NOT allow holding the HLink at a fixed rate UNLESS it detects an "error-correction" connection! Which means that IF AND ONLY IF the caller is using another error correcting V-Series modem and they establish an error-correction link, will the Hayes on the host stay at the fixed DTE or HLink speed. Under ALL other conditions, the Hayes 9600 V- Series will autobaud down to match the speed of the caller - even though the port was opened at 19200 on the host. DOOR authors must consider this when writing their applications for sysops with a Hayes 9600 V-Series on-line. In order to detect this, a DOOR author should interrogate the RBBS environment for the "/DTE" parm and adjust accordingly - based on the "Error Correcting Modem" flag in the DORINFO(X) file as well. Sidenote -------- A sidenote when configuring your high speed modem to operate at a maximum speed of 9600 bps. When you configure your modem's opening speed to be 9600 instead of 19200, some of the problems indicated above (such as failure to quickly detect a (Ctrl-K), etc.) are no longer a problem - since the code will automatically AutoBaud the modem to match the caller's connect speed. Since under that condition, output from the code is much more closely aligned to the speed at which the caller is able to receive the data, normal (Ctrl-K) operations are restored. Additionally, the Hayes 9600 V-Series modem automatically AutoBauds down unless an error-corrected connection is established - which means it as well will properly handle a caller's (Ctrl- K) requests. So, the bottom line is, do you want to provide better support for your low speed callers, or do you want to insure the maximum throughput for your high speed ones? The question of how you want to support the majority of your callers rests entirely with you. You need to decide what course of action you wish to take when configuring a 9600 bps high-speed modem. End of RBBS19200 Documentation RBBS-PC Operation with the Microcom AX2400c MNP-5 Modem -------------------------------------------------------- The following is a listing of Modem settings and configuration information for the use of a Microcom AX2400c with RBBS-PC operation, this setup allows callers at all baud rates to connect and perform normal operations. -> Modem Firmware Version (AT%V) --------------------------------- MNP Class 5 2400 Modem Rev 4.3 -> Switch Settings (Front AT%S0 - Rear AT%S1) --------------------------------------------- FRONT 1 2 3 4 5 6 7 8 9 10 U D D D D U U D U U REAR 1 2 3 4 5 6 7 8 D D D U D U D U -> Command Settings (AT\S) -------------------------- IDLE 000:00:00 LAST DIAL ID: MODEM BPS 2400 AT MODEM FLOW OFF AT\G0 MODEM MODE AUT AT\N3 AUTO ANS. OFF ATS0=0 SERIAL BPS 2400 AT BPS ADJUST OFF AT\J0 SERIAL FLOW BHW AT\Q3 PASS XON/XOFF OFF AT\X0 PARITY 8N AT BREAK 5 AT\K5 EXIT CHAR 043 ATS2=43 CMD ECHO OFF ATE0 RESULTS ON ATQ0 RESULT TYPE MNPL ATV1\V1 DATA ECHO OFF AT\E0 INACT TIMER 00 AT\T0 AUTO RETRAIN ON AT%E1 COMPRESSION OFF AT%C0 MAX BLK SIZE 256 AT\A3 AUTO BUFF 2 AT\C2 AUTO CHAR 013 AT%A13 MNP BLOCK OFF AT\L0 IP PROTO OFF AT\I0 EMULATING HP OFF AT\H0 PAUSE TIME 002 ATS8=2 DTR 2 AT&D2 CARR DET 1 AT&C1 DSR 0 AT\D0 RING IND 1 AT\R1 SPEAKER CTRL 1 ATM1 LEASE LINE OFF AT&L0 ASYNC/SYNC 0 AT&M0 CTS/RTS ON AT&R0 RDLB ENABLE OFF AT&T5 DIAL MODE 4 ATX4 PULSE DIAL US AT&P0 GUARD TONE 0 AT&G0 BELL ON ATB1 DISC DELAY 000 AT%D0 REM CHAR 000 AT*S0 REM ENABLE OFF AT*E0 REM SEC OFF AT*R0 -> S Register Default Settings (AT%R) ------------------------------------- REG DEC HEX REG DEC HEX S00 000 00H S14 008 08H S01 000 00H S15 000 00H S02 043 2BH S16 000 00H S03 013 0DH S17 000 00H S04 010 0AH S18 000 00H S05 008 08H S19 000 00H S06 002 02H S20 000 00H S07 030 1EH S21 048 30H S08 002 02H S22 118 76H S09 006 06H S23 022 16H S10 030 1EH S24 000 00H S11 000 00H S25 005 05H S12 050 32H S26 000 00H S13 000 00H S27 064 40H -> RBBS-PC Settings -------------------- Seconds to Wait for Carrier : 22 Opening Baud Rate (300-38400) : 9600 Modem Init. String : ATS2=255V1X4M0H0 Modem Off-Hook String : ATM0H1 Disable CTR/RTS Checking : N Keep Modem at Opening Speed : N Reset Modem During Recycle : Y Modem Off-Hook Durine Recycle : Y Answer on True Ring Detect : N Allow Callers at 7,E,1 : N Allow 300 Baud Callers : N (This is just a personal preference and does not affect operations either way) Notes: ------ These Settings and Initilization Strings have worked just fine for me with callers from 300 to 2400 baud. A 16550 UART was used in the 8mhz IBM AT's serial port as we are running a Lantastic Network and were experencing occasional Serial Input errors during Zmodem Uploads. An Alternative was to use the command "Handshake Slow" for DSZ, but it does slow transfers down a bit. I never experienced any problems with 300 baud callers, despite the note in the modems manual that says 300 baud is not supported with the AX2400C Greg Pal SysOp, NoPlace BBS 12/24/96/19.2b v.32 MNP (317)345-2375