Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!lll-tis!ptsfa!cogent!mark From: mark@cogent.UUCP (Captain Neptune) Newsgroups: comp.dcom.modems Subject: Re: MNP modems Message-ID: <378@cogent.UUCP> Date: Wed, 21-Oct-87 14:06:01 EDT Article-I.D.: cogent.378 Posted: Wed Oct 21 14:06:01 1987 Date-Received: Sat, 24-Oct-87 05:41:01 EDT References: <3013@husc6.UUCP> <377@cogent.UUCP> <7660@steinmetz.steinmetz.UUCP> Reply-To: mark@cogent.UUCP (PUT YOUR NAME HERE) Organization: Cogent Software Solutions, Stockton, CA Lines: 164 Keywords: MNP In article <7660@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <377@cogent.UUCP> mark@cogent.UUCP (PUT YOUR NAME HERE) writes: >|MNP as a protocol has failed to meet our needs consistently. Due to several >The only problem we have had is calling systems (a) from an MNP modem, ^^^^!?!?!? >(b) to a system without an MNP modem, (c) with a brain dead speed detect >which gets in a loop when the "are you MNP" message comes in. Only?! Only?! Oh good! So it is impossible for an MNP modem to log into most all UNIX boxes (unless you discard your baud rate selection :-( ). But that's okay! It is, after all, the *only* problem! It happened to us also with an MNP on both ends of the connection, by the way. >|I personally think that MNP is not very good at all and should be abandoned >|by the industry as a standard. > >Wonderful! One of the few places where we have a working standard and >you want to dump it. Yes. Telebit's PEP mode would be a very nice replacement. >MNP works just fine for most users, or the companies wouldn't offer it. It works for MSDOS puppies, I'm sure. It sucks on UNIX boxes, which demand more of modems. >If you don't believe in it, don't use it. I don't. Please refer to the following memo that I sent to our client and my boss on this matter. [ The memo is edited but still somewhat long. I've inserted comments in brackets like these ] ============================================================================== A Summary of the performance of the Telebit Trailblazer modem The Trailblazer modem has so far performed quite well. There have been minor difficulties, but our overall satisfaction has outweighed the difficulties encountered so far. What follows are details which explain the above statement, with unnecessary fine points deleted for brevity. I. What has worked. With the Trailblazer programmed to only communicate to the computer at 19.2Kbaud, a high-speed connection can be made to another Trailblazer modem, either connected to a remote HP computer or a stand-alone terminal. This connection has a reported throughput of up to 18000 bits per second. Aside from the expected glitch at the time of initial connection, no sign of line noise has been seen yet. The high speed connection gives the illusion of being directly connected to a local computer, with the only notable distance being that the output to the CRT screen may be sightly jumpy (i.e. a barely noticable stop-and-go feeling). Once the Trailblazer has been programmed to support UUCP protocol, then automatic file transfers (electronic mail, etc.) can be sent over the Trailblazer. We have calculated that data is transferred at a rate of 10000+ bits per second, as opposed to 1300+ bits per second by the Hayes 2400 baud modem. This represents a more than sixfold increase in speed. One megabyte of data can be transferred in about 12 minutes. A poor quality phone line will cause these improvement factors to decrease, but high speeds can still be expected. So far, we have managed to connect a Trailblazer into a Hayes 2400 baud modem sucessfully for a manual dial-in. The Trailblazer downshifts it's transmission speed to match the Hayes, and there is no error correction. To our convenience, the Trailblazer can still talk to the HP at 19.2Kbaud while talking to the Hayes at 2400 baud, so the interfacing to the HP is simplified. II. What has not worked yet. Slow modems (2400 baud or less, usually with no error correction) can connect to a Trailblazer, but output is garbled at times. This is almost certainly due to the flow control not being set properly between the Trailblazer and the HP. This is the one case where it is a disadvantage to have the Trailblazer-to-HP connection locked at 19.2Kbaud, for it makes flow control a pre-requisite. [ this problem has been resolved since the memo was written ] III. What to expect next. There is a good chance that the flow control problem can be worked out in the case of a slow modem dailing into a Trailblazer. However, if this ends up being not possible, then the slow modems can be programmatically restricted form calling Trailblazers. On the other hand, Trailblazers can be programatically allowed to call slow modems. Trailblazers will work on leased lines. They are currently set to a power level of -9.0 dBm. This value should be given to the supplier of the leased line for their verifiaction. Special leased lines (such as high speed) are not needed. Since conventional voice lines allow the Trailblazer to reach it's maximum speed of 18000 bits per second, a leased line of comparable quality would be adequate, as well as less costly. MNP error correction is supported by the Trailblazer, but I would discourage it's use for several reasons: a. We have no MNP-type modems in use now. b. All MNP-type modems that we have tried on UNIX systems have failed to work properly. c. The 'PEP' mode which the Trailblazer employs is superior in performance and functionality to MNP correction. It is my own opinion that the very design of MNP is flawed, and that MNP is useless beyond the realm of the attended PC. [note: ok, *maybe* unattended, but I'm still not impressed!] The Achilles heel of MNP is it's poorly designed method of 'negotiating' (coming to an agreement about whether to use error-correction or not) with the other modem at the time of connection. When a MNP-type modem is making a connection to another modem, it returns messages to the computer saying "We're connected okay" before the negotiation begins. Thus, any computer that begins outputting data immediately upon connection (i.e. most big computers!) will interfere with the modems, which are busy trying to decide if they should do error correction or not. This is not just careless, this is downright stupid! Furthermore, the negotiation of error correction between modems includes the sending of BREAK signals, which causes most UNIX systems to repeat their login prompts, thus aggrevating the modems further. The end result is usually the computer's login routine quarreling with the modem's negotiation attmepts in an endless loop. The designers of MNP would seem to have never tested it on anything beyond a PC. If they had, then why would three MNP modems fail to work on a UNIX system after much effort while a Trailblazer worked with very little difficulty? [ If you want to assume that they failed just because we're stupid, then go ahead. It doesn't matter to me. ] Thus I conclude that the design of MNP error correction is inherently flawed and careless. MNP is becoming the industry standard, but I am of the opinion that if Telebit's PEP protocol were to supplant MNP as the standard, then the entire computer field would benefit. -- ############################################################################## # Mark ###################### Ernie: Gee, Bert! Where'd all your files go ? # # Steven #################### Bert: My files! Er-r-r-r-r-r-rnie-e-e-e-e !! # # Jeghers ########## {ihnp4,cbosgd,lll-lcc,lll-crg}|{dual,ptsfa}!cogent!mark # ############################################################################## # Standard Disclaimer: Don't sue me. Sue my company. They have more money. # ##############################################################################