kiely@lownlab.harvard.edu (James P. Kiely) (10/18/87)
Does anyone know of 2400 baud modems with MNP other than those made by MicroCom and MultiTech? Please specify the level of MNP available from other vendors. Is it worth the increased cost to buy modems with MNP? Tymnet and Telenet support some level of MNP but I get different answers as to what level depending on who I talk to. Does anyone know the correct story? NAME: James P. Kiely USPS: Kiely Laboratories USENET: ...!harvard!lownlab!kiely P.O. Box 624 DOMAIN: kiely@lownlab.harvard.edu Allston, MA 02134-0624 PHONE: +1 617 782 4136 USA
chapman@eris.BERKELEY.EDU (Brent Chapman) (10/19/87)
In article <3013@husc6.UUCP> kiely@lownlab.harvard.edu (James P. Kiely) writes: >Does anyone know of 2400 baud modems with MNP other than >those made by MicroCom and MultiTech? US Robotics and Black Box both have 2400 baud MNP modems. The US Robotics 2400e is MNP Level 3, and the Black Box (I don't remember the name) I think is Level 4. I wouldn't recommend the Black Box modems. I ended up returning ours for a refund; they were expensive (about $550), and not as compatible as they should have been. On the other hand, I have no problems at all recommending the US Robotics 2400e modems. I think they're wonderful. They work, they're compatible, they're cheap (we shopped around and bought 7 of them for $405 each), and the documentation and firmware are both excellent. -Brent -- Brent Chapman Senior Programmer/Analyst koala!brent@lll-tis.arpa Capital Market Technology, Inc. lll-tis!koala!brent 1995 University Ave., Suite 390 Phone: 415/540-6400 Berkeley, CA 94704
guardian@laidbak.UUCP (Harry Skelton) (10/19/87)
In article <5506@jade.BERKELEY.EDU> chapman@eris.BERKELEY.EDU (Brent Chapman) writes: > >US Robotics and Black Box both have 2400 baud MNP modems. The US Robotics >2400e is MNP Level 3, and the Black Box (I don't remember the name) I think >is Level 4. I think USR is up to Level 5 now. I know they are on the 9600HST (due to trailblazer modems being faster) but do not know if the 2400e's are upgraded yet. One would think so.
mark@cogent.UUCP (Captain Neptune) (10/19/87)
In article <3013@husc6.UUCP> kiely@lownlab.harvard.edu (James P. Kiely) writes: > >Does anyone know of 2400 baud modems with MNP other than >those made by MicroCom and MultiTech? >Please specify the level of MNP available from other vendors. >Is it worth the increased cost to buy modems with MNP? MNP as a protocol has failed to meet our needs consistently. Due to several aspects of UN*X that MNP design neglects and/or conflicts with, we have never gotten an MNP modem to work on our UN*X box. We went to a different protocol altogether for error correction and it worked uright away. I personally think that MNP is not very good at all and should be abandoned by the industry as a standard. -- ############################################################################## # 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. # ##############################################################################
jbs@eddie.MIT.EDU (Jeff Siegal) (10/20/87)
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 >aspects of UN*X that MNP design neglects and/or conflicts with, we have never >gotten an MNP modem to work on our UN*X box. [...] Please me a bit more specific. I haven't looked closely at MNP, but I am interested in the observations of someone who has. Jeff Siegal
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (10/20/87)
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 |aspects of UN*X that MNP design neglects and/or conflicts with, we have never |gotten an MNP modem to work on our UN*X box. We went to a different protocol |altogether for error correction and it worked uright away. 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. uucp will run alright over them, but protocols such as zmodem produce higher throughput. | |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. Do you see what has happened in the 9600 baud market due to lack of standards? MNP works just fine for most users, or the companies wouldn't offer it. If you don't believe in it, don't use it. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
chapman@eris.BERKELEY.EDU (Brent Chapman) (10/21/87)
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 >aspects of UN*X that MNP design neglects and/or conflicts with, we have never >gotten an MNP modem to work on our UN*X box. We went to a different protocol >altogether for error correction and it worked uright away. >I personally think that MNP is not very good at all and should be abandoned >by the industry as a standard. Are you certain it's MNP, and not the modem itself, that's giving you problems? I had major problems getting my original MNP modems (from Black Box) to work with my UNIX boxes; I eventually ended up returning those modems for a refund (one of the _good_ things about Black Box). I then switched (on the recommendation of John Gilmore (gnu@hoptoad) and several others) to US Robotics 2400e MNP modems. I've got several of them now, on UNIX boxes (Suns), PCs, my Amiga, and dumb terminals, and they work just beautifully. I spend at least 4-6 hours per day logged in to one machine or another through them, and have no problems. I have no reservations in recommending the US Robotics 2400e modems. -Brent -- Brent Chapman Senior Programmer/Analyst koala!brent@lll-tis.arpa Capital Market Technology, Inc. lll-tis!koala!brent 1995 University Ave., Suite 390 Phone: 415/540-6400 Berkeley, CA 94704
mark@cogent.UUCP (Captain Neptune) (10/21/87)
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. # ##############################################################################
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (10/22/87)
In article <378@cogent.UUCP> mark@cogent.UUCP (PUT YOUR NAME HERE) writes: |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. Actually, all MNP modems I have seen allow the MNP to either be made automatic or switched off. There may be some checp brand which doesn't do this under software control, but I haven't seen it. I just turn MNP off when dialing certain systems. I had to diddle my dialer a bit, but the result is worth it. The problem only occurred with a few system which don't speed detect reliably when called with any modem, so I don't see that this is a problem solely with MNP. From the number of postings on this topic in the last few months, I suspect that there is a general problem with speed detect on some systems. I run into both MNP and non-MNP modems without problems. Perhaps as someone else suggested you might care to try another modem brand. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
kim@mcrware.UUCP (Kim Kempf) (10/23/87)
> > I have no reservations in recommending the US Robotics 2400e modems. > I've been using a USR Courier HST (9600 baud) modem ($795) over dialup lines quite heavily with almost no problems. I think this beast uses a USR-proprietary error correction scheme so it can only talk to another Courier modem. The only problem is establishing the connection, but once hooked up, its 9600 baud dialup for hours.
day@grand.UUCP (Dave Yost) (10/23/87)
In article <7675@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: >I just turn MNP off when dialing certain systems. >I had to diddle my dialer a bit, but the result is worth it. I'm familiar with this approach. Sure, you can diddle your dialer to turn off MNP, but it is not possible to reliably turn it back on again at the end of an outgoing uucico connection. Problem is (at least on the MultiTech) that there aren't separate settings for dialin and dialout auto-MNP mode. So, when a uucico dialout connection finishes, auto-MNP mode is now off for dialins. --dave yost P.S. I wish these backward hi-tech comanies like MultiTech would get hooked up to the net! They have modems coming out of their ears; all they need is a computer.
daveb@geac.UUCP (10/23/87)
|In article <377@cogent.UUCP> mark@cogent.UUCP writes: ||MNP as a protocol has failed to meet our needs consistently. Due to several ||aspects of UN*X that MNP design neglects and/or conflicts with, we have never ||gotten an MNP modem to work on our UN*X box. We went to a different protocol ||altogether for error correction and it worked right away. In article <7660@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: |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. uucp will |run alright over them, but protocols such as zmodem produce higher |throughput. The quality (behavior under unexpected conditions) of MNP implementations varies wildly with who did the implementation. At least one was done by two persons on this net, and tends to work quite well with Unix and unix tools. At least one other was done *rather* badly by persons unknown. Regrettably, I do not know which manufacturers purchased which implementation... --dave -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
berger@datacube.UUCP (10/24/87)
We've been using MultiTech 224E MNP modems on our Pyramid Unix machine for
over a year. We've had absolutely no problems using it both for dial in
and dial out. We talk to MNP and non-MNP modems in both directions.
The only problem we have ever had is that the MultiTechs seem to not like
power glitches. After some power glitches/failures, they may get wierded
out until reset.
This does not mean that they are better than the Trailblaizer (we're getting
one of those as well) but from my experience, MNP should not be written off.
Bob Berger
Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960
VOICE: 617-535-6644; FAX: (617) 535-5643; TWX: (710) 347-0125
UUCP: berger@datacube.COM, rutgers!datacube!berger, ihnp4!datacube!berger
{cbosgd,cuae2,mit-eddie}!mirror!datacube!bergerdavidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (10/26/87)
In article <391@grand.UUCP> day@grand.UUCP (Dave Yost) writes: |In article <7675@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: |>I just turn MNP off when dialing certain systems. |>I had to diddle my dialer a bit, but the result is worth it. | |I'm familiar with this approach. Sure, you can diddle your dialer |to turn off MNP, but it is not possible to reliably turn it back on |again at the end of an outgoing uucico connection. Problem is (at dialer diddling: send AT, get the modem's attention lookup the phone number in "/usr/lib/uucp/has.MNP" set echo, quiet, MNP option and attention char dial and wait for connect use attn char: reset MNP option and attn char Much easier to set the mode after the dial, before the connection. This may cause problems with some modems... they may not like switching MNP options on the fly. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
SNELSON@STL-HOST1.ARPA (10/27/87)
I THINK SOMEONE HIT THE NAIL ON THE HEAD YESTERDAY WHEN THEY MENTIONED PORTS NOT (CAN'T) AUTOBAUDING. STEVE
bytebug@felix.UUCP (Roger L. Long) (10/29/87)
In article <378@cogent.UUCP> mark@cogent.UUCP (PUT YOUR NAME HERE) writes: |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. Our site is using Racal Vadic 2400PA modems which you can set to transmit to the host computer at some fixed baud rate. That way, there's no baud rate selection on the host side, since the modem automatically converts to the set baud rate. So what's the big fuss? -- Roger L. Long FileNet Corp {hplabs,trwrb}!felix!bytebug
news@mfci.UUCP (Usenet) (11/09/87)
We recently got a MultiModem 224e with MNP class 5, but there seems to be no way to have class 5 to be invoked automatically (like class 3and 4). Am I missing something ? Thanks
ashok@softart.UUCP (11/12/87)
> We recently got a MultiModem 224e with MNP class 5, but there seems to be > no way to have class 5 to be invoked automatically (like class 3and 4). > Am I missing something ? > Thanks I don't know about the MultiModem 224e but with the Microcom AX-2400C (The C signifies Class 5), there is a special command to turn on class 5. The command is AT%C1. You can save away this setting in the non-volatile RAM so that the modem will always try class 5. There might be something like this on the MultiModem. Check your manual. ------------------------- Ashok C. Patel Softart Microsystems Inc.
CES8@psuvm.psu.edu (06/17/90)
A number of modems now offer MNP Class 5 data compression and
MNP Class 4 error control. I would like to know how widespread is the
host support and use of MNP modems.
I am thinking about upgrading to an MNP modem, but it seems like
the systems I normally use do not support MNP modems. Any experiences
with these modems?
Thanks in advance for your responses.
CES8@psuvm.psu.edu C.E. Soares
224 Research Building East
NASA Center for Space Propulsion Eng.
The Pennsylvania State University
an MNP modem, but the systems I normally use don't seem to supportcpcahil@virtech.uucp (Conor P. Cahill) (06/18/90)
In article <12785@cbmvax.commodore.com> grr@cbmvax (George Robbins) writes: >In some environments, such as interactive dial-up access over noisey lines >or file transfer with dumb PC based software, MNP probably as some real >advantages - on the other hand if you're buying a modem for your home unix >system, you'd probably never use it... If you are buying a modem today, I would ensure that you get MNP. You might not use it all the time, but you will always be prepared. I have 5 modems attached to our system, all of which are mnp and one of which is a T2500 which I use for uucp connections. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
brendan@cs.widener.edu (Brendan Kehoe) (04/16/91)
In <13472@ucrmath.ucr.edu>, bruce@watnxt2.ucr.edu writes: >On that subject, does anyone know how those error-correcting modems work? <Boing> you just leaped into the comp.dcom.modems realm of expertise. -- Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu Widener University in Chester, PA A Bloody Sun-Dec War Zone "Does this person look relaxed to you? Well, it's actually an experiment of Contour's new 565-E chair!"
dick@ahds.UUCP (Dick Heijne CCS/TS) (04/16/91)
In article <3B3_BDF@cs.widener.edu>, brendan@cs.widener.edu (Brendan Kehoe) writes: > In <13472@ucrmath.ucr.edu>, bruce@watnxt2.ucr.edu writes: > >On that subject, does anyone know how those error-correcting modems work? > > <Boing> you just leaped into the comp.dcom.modems realm of expertise. > Brief summary: MNP (Microcom Networking Protocol) transfers an asynchronous datastream into a synchronous datastream by removing the start- and stopbit. This leaves only the eight databits, thus reducing the amount of bits by 20%. MNP adds about 3% on overhead data. I don't know about class 1 and 2 (as far as I know they are hardly used anymore). Class 3 is bit-oriented and has an effectivity of about 108%. Each packet has an 16-bit CRC number added to each packet. A disagreement in the CRC causes (within limits) retransmission of data. Since the packets are numbered, buffering is no problem. This is often needed for interspeeding. If retransmission is needed, the retransmission starts with the packet BEFORE the offending packet, and all packets since the disagreed packet are retransmitted (this mechanism is known as the 'go-back-n' error-correction method, where 'n' is the number of the wrong block. Class 4 only generates larger packets, thus reducing overhead and increasing the effectivity to about 122%. Class 5 is a Class 4 with datacompression added to it. The effectivity is thereby increased to 160-200%. The used technique is known as Adaptive Frequency Encoding, where the 8 bits are converted into characters of at least 4 bits. The used compression method is known as Run-Length Encoding which will send a character, that is repeated more than three times as a single numbered code; next there are two ways of follow-up: if more than three occurences of the same characters are found after another, this compression takes place. The second one is based on Dynamic Tabulation of repeating characters: the table is updated by the frequency of self-repeating characters. The latter technique is in favor, since the table is updated real-time during transfer. If you want more, read about it! Hope this brief explanation has confused you forever :-)) Dick.