tony@killer.UUCP (Tony Holden) (01/23/88)
Is it hype or is it real? I've seen ads claiming that with the various MNP levels that the throughput on a 2400 baud modem is that of 9600 baud. Is it hype or is it real? Tony Holden ihnp4!killer!tony
chapman@eris (Brent Chapman) (01/24/88)
In article <3027@killer.UUCP> tony@killer.UUCP (Tony Holden) writes: >I've seen ads claiming that with the various MNP levels that the throughput >on a 2400 baud modem is that of 9600 baud. > >Is it hype or is it real? It's hype. MNP is an error detection and correction protocol. A modem running at 2400 baud with MNP will probably actually have slightly (_very_ slightly) lower throughput than without MNP, because of the extra bits needed for the protocol. I happen to think it's worth it, though, because of the error correction. I spend lots of time dialed into various systems in Berkeley (which has _lousy_ line quality) using a USRobotics Courier 2400e MNP modem at home (I'm using it now, as a matter of fact). I always dial in at 2400 baud; sometimes I get an MNP modem on the other end, and sometimes I don't. I don't notice any difference in speed when MNP is in use compared to when it isn't (and believe me, I'd _notice_ a difference of 9600 vs. 2400 baud). The only difference is that occasionally when not using MNP, I get line garbage, and when using MNP, output will pause for a half-second (while line garbage is detected and corrected), then continue. -Brent -- Brent Chapman Capital Market Technology, Inc. Senior Programmer/Analyst 1995 University Ave., Suite 390 {lll-tis,ucbvax!cogsci}!capmkt!brent Berkeley, CA 94704 capmkt!brent@{lll-tis.arpa,cogsci.berkeley.edu} Phone: 415/540-6400 dial into
chapman@eris (Brent Chapman) (01/25/88)
In article <6678@agate.BERKELEY.EDU>, I write: #In article <3027@killer.UUCP> tony@killer.UUCP (Tony Holden) writes: #>I've seen ads claiming that with the various MNP levels that the throughput #>on a 2400 baud modem is that of 9600 baud. #> #>Is it hype or is it real? #It's hype. MNP is an error detection and correction protocol. A modem running #at 2400 baud with MNP will probably actually have slightly (_very_ slightly) #lower throughput than without MNP, because of the extra bits needed for the #protocol. I happen to think it's worth it, though, because of the error #correction. I've been informed that higher levels of MNP include compression as well as error detection and correction. Even so, I find a 4 to 1 compression ratio hard to believe under any "real" conditions, especially in interactive use. The "compress" program, which is pretty good according to the people I know who know about such things (I don't), rarely manages a 4:1 ratio, and then only on large, fairly repetitious files; I doubt the ability of any modem to do much better, because it can't use _too_ large a "block size" for compression because of response time considerations. [I'd be happy to be shown to be wrong, however...] -Brent -- Brent Chapman Capital Market Technology, Inc. Senior Programmer/Analyst 1995 University Ave., Suite 390 {lll-tis,ucbvax!cogsci}!capmkt!brent Berkeley, CA 94704 capmkt!brent@{lll-tis.arpa,cogsci.berkeley.edu} Phone: 415/540-6400
ttang@puff.cs.wisc.edu (Theodore Tang @ Univ of Wisconsin-Madison) (01/26/88)
In article <6678@agate.BERKELEY.EDU>, chapman@eris (Brent Chapman) writes: > It's hype. MNP is an error detection and correction protocol. A modem running > at 2400 baud with MNP will probably actually have slightly (_very_ slightly) > lower throughput than without MNP, because of the extra bits needed for the > protocol. I happen to think it's worth it, though, because of the error > correction. > > I spend lots of time dialed into various systems in Berkeley (which has _lousy_ > line quality) using a USRobotics Courier 2400e MNP modem at home (I'm using it [ basic principle of MNP description removed ] > -Brent Brent, Actually this depends on which level of MNP you have, which is 3 with the USR Coursier 2400e. I have USR's HST which has MNP 5 which claims to have a throughput of up to 19200 baud (my modem is rated normally w/o MNP at 9600) using hardware data compression under idea situations (ie text). Ted Tang ttang@puff.wisc.edu.UUCP
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (01/26/88)
In article <6678@agate.BERKELEY.EDU> chapman@eris.UUCP (Brent Chapman) writes: | In article <3027@killer.UUCP> tony@killer.UUCP (Tony Holden) writes: | | >I've seen ads claiming that with the various MNP levels that the throughput | >on a 2400 baud modem is that of 9600 baud. | > | >Is it hype or is it real? | | It's hype. MNP is an error detection and correction protocol. A modem running | at 2400 baud with MNP will probably actually have slightly (_very_ slightly) | lower throughput than without MNP, because of the extra bits needed for the | protocol. I happen to think it's worth it, though, because of the error | correction. This statement is, at best, partially correct. MNP levels 4 and 5 include data compression, and on text data the effective thruput will be just about doubled. MNP 1-3 levels are error correcting only. You will get 4000-4400 baud effective at 2400, up in the 17k range with 9600 baud. Obviously you won't get this if you restrict the flow of data to 2400 baud. The secret is to let the modem do speed conversion. {you}---9600baud---{your modem}======== || || || || 2400 baud dialup (MNP class 4 or more) || || || || {them}---9600 baud---{their modem}===== The thing which makes this work is the 9600 baud between you and your modem. The modem will do flow control to adjust the speed of the data you send, and uses the higher speed to deliver the data as fast as it's decompressed. If you fail to understand that the modem must have a higher speed path to deliver the compressed data to yourterminal or system, you will not see an improvement. I knew someone who connected his new 2400 baud modems using 1200 baud and felt that he didn't see much difference. Others using the same hardware felt that it was "much faster." This works on MultiTech 224E (with new ROM) and several other modems which support MNP class 5. Your milage may vary. Already compressed data will not run much faster. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
david@ms.uky.edu (David Herron -- Resident E-mail Hack) (01/26/88)
In article <17586@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes: >As someone already pointed out MNP only makes the data rate slower, it's >an error correction protocol. The misunderstanding might be from the >misapplication of the term BAUD. BAUD is the signalling rate. Bits >per second (bps) actually tells you how much data you are moving. Yeah, it does slow down the actual bit rate on the phone line but with the higher levels of the protocol (I forget where this kicks in) there is Lempel-Ziv compression going on at varying levels of precision. The Lempel-Ziv algorithm is the same one that drives the compress program, and as users of that program are no doubt familiar with ... the compression averages about 50% for normal text files. With files that have lots of repetition, the compression can be much higher ... UUCP log files, for instance, tend to have 90% compression ratio's. While technically this is all happening at the same 1200 bits per second signalling rate (BAUD), the end user is more interested in the throughput in bytes per second. -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- <---- It takes more than a good memory to have good memories.
csg@pyramid.pyramid.com (Carl S. Gutekunst) (01/26/88)
In article <3027@killer.UUCP> tony@killer.UUCP (Tony Holden) writes: >I've seen ads claiming that with the various MNP levels that the throughput >on a 2400 baud modem is that of 9600 baud. > >Is it hype or is it real? Mostly hyperbole. At level 2, MNP is slightly slower than conventional 2400bps modems because of the error correction overhead. At level 3, there is a 20% boost that results from removal of the stop and start bits; the modems run synchronously between each other. It is enough that if you set the interface speed at 4800bps, uucico sees throughput around 2600 bps or so. By level 5 you have compression, which is usually claimed to produce 4800 bps throughput. At level 6 you have more compression, and there are well chosen data patterns that will transfer at up to 9600 bps. But throughput on real data is going to be closer to 4800 bps, and on binary files or compressed data (like that from compress or pack) it could be much lower. <csg>
chris@mimsy.UUCP (Chris Torek) (01/26/88)
In article <9308@steinmetz.steinmetz.UUCP> davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) writes: [re compression at higher MNP levels] >The secret is to let the modem do speed conversion. ... >The modem will do flow control to adjust the speed of the data ... ... and therein lies the problem. Just *how* does the modem do flow control? The Telebit Trailblazer Plus has five or six different options. I suspect a number of modems have two: No flow control, or DC1/DC3 (also known as ^S/^Q) flow control. Hardware flow control using RTS/CTS is possible, and when it can be used, works perfectly; unfortunately, it often cannot be used, partly because it is technically `illegal'. Ideally, someday, someone will define a standard for compressed data between cooperating devices, with some sort of control built in (windowing comes to mind), manufacturers will build terminals and modems supporting this protocol, and everything will plug in from one end to the other with no `special' bit patterns visible to users. Since without some sort of configuration---manual or automatic--- such devices will not interoperate with existing RS232C, and since there is no installed base of such devices, there is no real drive for this to happen any time soon. Perhaps some of the more visionary and capable vendors (such as I perceive Telebit to be) will help get this started. (And indeed, Telebit's UUCP g protocol spoofing is a start.) [I suppose this article warrants a disclaimer. I am not associated in any way with Telebit. I am just extremely impressed with their modems. They are one of the few companies I have seen build clever hardware *and* hire good programmers, rather than having the hardware engineers do all the firmware!] -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
steve@raspail.UUCP (Steve Schonberger) (01/26/88)
In article <1390@puff.cs.wisc.edu>, ttang@puff.cs.wisc.edu (Theodore Tang @ Univ of Wisconsin-Madison) writes: > using hardware data compression under idea situations (ie text). ------------------------------- But it doesn't help at all if you are transmitting something that is already compressed, like UUCP files that are compress-ed, or ARC files on BBSs, or GIF image files, or any number of other packed files. The "compression" may even worsen throughput in those cases, due to the overhead being added on top of incompressible data. Since almost all of the modeming I do that I need high speed for (see above exmaples) is already packed, it is hype in my book. But for someone who does online screen editing via modem, it would be a great help, on top of the error correction (which is also in software in the examples that apply to me). Each to his/her own... (My own opinions, not necessarily those of my employer.) Steve Schonberger
ane@hal.UUCP (Aydin "Bif" Edguer) (01/26/88)
In article <6701@agate.BERKELEY.EDU> chapman@eris.UUCP (Brent Chapman) writes: >In article <6678@agate.BERKELEY.EDU>, ??? writes: >#In article <3027@killer.UUCP> tony@killer.UUCP (Tony Holden) writes: > >#>I've seen ads claiming that with the various MNP levels that the throughput >#>on a 2400 baud modem is that of 9600 baud. >#> >#>Is it hype or is it real? > >#It's hype. MNP is an error detection and correction protocol. A modem >#running >#at 2400 baud with MNP will probably actually have slightly (_very_ slightly) >#lower throughput than without MNP, because of the extra bits needed for the >#protocol. I happen to think it's worth it, though, because of the error >#correction. > >I've been informed that higher levels of MNP include compression as well as >error detection and correction. Even so, I find a 4 to 1 compression ratio >hard to believe under any "real" conditions, especially in interactive use. >The "compress" program, which is pretty good according to the people I know >who know about such things (I don't), rarely manages a 4:1 ratio, and then >only on large, fairly repetitious files; I doubt the ability of any modem >to do much better, because it can't use _too_ large a "block size" for >compression because of response time considerations. [I'd be happy to >be shown to be wrong, however...] I have yet to see an ad for a modem that transmits information at 9600 baud over a 2400 baud link and I would be inclined to disbelieve it... HOWEVER... MNP DOES NOT SLOW DOWN _CORRECT_ DATA TRANSMISSION! MNP SPEEDS UP _CORRECT_ DATA TRANSMISSION! Please note I said correct data transmission. MNP is first and foremost an error correction protocol and thus over a noisy line, it will send a packet till it is correct and thus could slow down the total time of transmission. (but it will be right) How does it speed up transmission? Good question. I would say RTFM but there isn't one available. So instead I will include an excerpt from another document. It only covers up to Class 4 MNP. Microcom has licensed people up to Class 6 MNP (and I saw a listing for a Class 8 MNP modem - I think someone made a typo but I never bother to call....) Aydin Edguer !cbosgd \ !decvax -+ !mandrill.CWRU.edu!hal!ane !sun / ================================ From the Bytecom MNP Introductory document.... MNP is an acronym for Microcom Networking Protocol, which was devised to provide a method of error detection and a means to correct erroneous data received. Data are grouped together and sent in packets called Link Transfer (data) frames and are acknowledged by Link Acknowledgement frames. Each data frame contains a 16 bit Cyclic Redundancy Check (CRC) character. Any received data frame that contains a CRC that does not match the locally computed CRC is said to be "broken". Detection of a broken frame causes the modem to send a negative acknowledgement to the remote system, which then retransmits the frame. The likelihood of receiving an undetected error is extremely small when this method is employed. There are several levels of operation available, which are referred to as Service Classes. The service class refers to framing techniques that the modem uses to transfer data. Class 1 uses standard asynchronous framing techniques for data transfer during half duplex operation, which is not used by full duplex modems. Class 2 uses standard asynchronous framing techniques for data transfer during full duplex operation. Class 3 uses synchronous framing techniques for data transfer during full duplex operation. Asynchronous data framing start and stop bits are "stripped" from each character prior to transmission, resulting in a 20% reduction in the number of data bits to be transmitted when using ten bits per character. This produces a data transfer rate effectively greater than the modem's data transmission rate (bps), which is 2600 bps compared to 2400 bps, respectively. Class 4 optimizes performance by using more efficient frame headers and allowing for larger data frame capability. Data frame size is adjusted in size as the modem detects higher data error rates. Data frames are reduced in size when the modem detects higher rates of data frame retransmissions.... When the modem detects less data frame retransmissions, the data frame size is increased. Effective data transfer rates up to 2900 bps compared to 2400 bps are possible when this technique is utilized.
jfs@ih1ap.ATT.COM (J.F. Shumway) (01/27/88)
In article <6701@agate.BERKELEY.EDU> chapman@eris.UUCP (Brent Chapman) writes: >I've been informed that higher levels of MNP include compression as well as >error detection and correction. Even so, I find a 4 to 1 compression ratio >hard to believe under any "real" conditions, especially in interactive use. Yes, it is hard to beleive, indeed. >The "compress" program, which is pretty good according to the people I know >who know about such things (I don't), rarely manages a 4:1 ratio, and then >only on large, fairly repetitious files; I doubt the ability of any modem >to do much better, because it can't use _too_ large a "block size" for >compression because of response time considerations. [I'd be happy to >be shown to be wrong, however...] Yer right. Compression in the higher level MNP protocols is done by simple run length encoding. A string of several identical characters in a row are encoded as the character and the length of the sequence. This may be a win if your data is, say, blank (\040) padded into 80-80 card images for shipment to some IBM dinosaur, but it doesn't gain you much in a Unix environment. The compress program you mention uses the Lempel-Ziev (sp?) adaptive Huffman encoding compression alogorithm. I understand that LZ compression is performed by the Telebit Trailblazer in its intermodem packets when emulating the uucp "g" protocol. -- Jesse Fred Shumway ihnp4!ih1ap!jfs
root@conexch.UUCP (Larry Dighera) (01/27/88)
In article <6678@agate.BERKELEY.EDU> chapman@eris.UUCP (Brent Chapman) writes: <In article <3027@killer.UUCP> tony@killer.UUCP (Tony Holden) writes: < <>I've seen ads claiming that with the various MNP levels that the throughput <>on a 2400 baud modem is that of 9600 baud. <> <>Is it hype or is it real? < <It's hype. MNP is an error detection and correction protocol. A modem running <at 2400 baud with MNP will probably actually have slightly (_very_ slightly) <lower throughput than without MNP, because of the extra bits needed for the <protocol. I happen to think it's worth it, though, because of the error <correction. Class 5 MNP protocol employes Lempel-Zev compression to achieve enhanced throughput. Look into the Multi-Tech MultiModems; they now do class 5 MNP. They also support "Speed Conversion" (a necessity for class 5 MNP) which obviates the necessity of a caller sending a BREAK to get getty to cycle through the /etc/gettydefs entries. Very useful on Un*x systems. Larry Dighera -- USPS: The Consultants' Exchange, PO Box 12100, Santa Ana, CA 92712 TELE: (714) 842-6348: BBS (N81); (714) 842-5851: Xenix guest account (E71) UUCP: conexch Any ACU 2400 17148425851 ogin:-""-ogin:-""-ogin: nuucp UUCP: ...!ucbvax!ucivax!mickey!conexch!root || ...!trwrb!ucla-an!conexch!root
finkel@TAURUS.BITNET (01/29/88)
Since we were in the MNP business, I have a question: I have seen an ad for a program which emulates MNP by software. (for PCDOS). According to what I know, ( and was also posted here ), MNP protocol above level 2 ( level 3 and up ) uses synchronous mode ( no start/stop bits ) in order to gain a speed increase. I understand that it's not a problem to emulate MNP level 1,2 by software, but is that possible with levels 3 and up? Can you run a synchronous protocol over a normal rs232 hardware ( say, like the PC), that will be compatible with MNP? I don't remember the level mentioned in the ad, if it was mentioned at all. Udi Finkelstein finkel@math.tau.ac.il or finkel@taurus.bitnet
jbs@eddie.MIT.EDU (Jeff Siegal) (01/29/88)
In article <959@ih1ap.ATT.COM> jfs@ih1ap.UUCP (J.F. Shumway) writes: >Yer right. Compression in the higher level MNP protocols is done by >simple run length encoding. [...] >This may be a win if your data is, say, blank (\040) >padded into 80-80 card images for shipment to some IBM dinosaur, >but it doesn't gain you much in a Unix environment. I don't think this is true. The Microcom literature I've seen claims that MNP uses dynamic bit lengths for characters, so more frequently used characters use less bits (like Huffman). So even normal interactive use will benefit somewhat. Jeff Siegal
clarke@acheron.UUCP (Ed Clarke) (01/31/88)
in article <17586@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie) says: > > As someone already pointed out MNP only makes the data rate slower, it's > MNP Classes: 1 - Block Mode, Half duplex, slowest ( nobody uses this one ) 2 - Stream Mode, Full duplex, 84% of non-MNP chars per second 3 - Class 2 + synchronous transmission. 254 chars/sec @ 2400 baud ( due to no start or stop bit overhead, 8 bits/char vs 10 ) 4 - Class 3 + bigger blocks + smaller header. 276 chars/sec @ 2400 baud 5 - Class 4 + data compression. Throughput varies with data. May be less efficient than class 4. The above information is from the USR Courier HST modem instruction book and the October, 1987 addendum to same. Note that the initial MNP handshake may prevent connection to a non-MNP modem. Courier recommends that you disable MNP if you know that the other modem does not support it. The above data presumes no errors. If you get errors, then throughput will drop to much lower rates. By the way, the compression description in the HST manual sounds like a simple HASP compress, not LZ compression. I could be wrong though ( nothing like asking for flames! ). ALSO!!! You have to be feeding the modem faster than 2400 baud (or 1200) to get ANY improvement at all. 2400 in = 2400 out, and doesn't matter if you have a T1 line in between. The HST and others will accept 19200 in and out, with a slower link in between (2400 for instance). They handshake with CTS or by XON/XOFF protocols. Ed Clarke, Jr.