TIMBUCK@VTVM1.CC.VT.EDU (10/31/90)
The Cardinal MB2400EX does NOT have built-in MNP compression. However, most Cardinal modems are shipped with a software package called Flashlink which does MNP compression with software. As I understand it, MNP compression is independent of whether or not the files are already compressed. However, the modem at the "other end" must also use MNP for you to use it. Additionally, only certain file transfer protocols use MNP (e.g. YMODEM-g). Hope I've been of some help to you. Tim Buck TIMBUCK@VTVM1
root@zswamp.fidonet.org (Geoffrey Welsh) (11/01/90)
> From: TIMBUCK@VTVM1.CC.VT.EDU > Message-ID: <9011010804.AA05071@ucbvax.Berkeley.EDU> > > As I understand it, MNP compression is independent of whether or not the > files are already compressed. However, the modem at the "other end" must > also use MNP for you to use it. Additionally, only certain file transfer > protocols use MNP (e.g. YMODEM-g). I don't know where you got these ideas! Modems which support MNP internally get a 20% boost in performance by stripping start and stop bits from the data stream (MNP Service Class 3), but this is not considered data compression. MNP5 uses a type of LZW compression algorithm, but its 'on the fly' approach has some weaknesses, including the fact that MNP5 will *lose ground* on well-compressed files (i.e. a .ZIP file moves faster with MNP5 *dis*abled than with it enabled!). It's true that both ends of a connect must support MNP for it to be effective, but that's like saying that a 2400 bps modem only works at that speed when calling another modem with 2400 bps capabilities... it should be obvious. As for your claim that "only certain ... protocols use MNP", I am not sure what you mean. While some protocols (such as YMODEM-G, XMODEM-1K-G, UUCP-e, etc.) *depend* on an error-free data link, no protocols are specific to MNP and MNP3's (and MNP5's) performance boosts can be used to advantage by just about any protocol. In some rare cirucmstances, MNP's packetizing delays may degrade the performance of non-windowed protocols with small packets, but this is purely a coincidental side-effect. -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 MC Hammer, n. Device used to ensure firm seating of MicroChannel boards Try our new Bud 'C' compiler... it specializes in 'case' statements!
tnixon@hayes.uucp (Toby Nixon) (11/03/90)
In article <3182.27310BB8@zswamp.fidonet.org>, root@zswamp.fidonet.org (Geoffrey Welsh) writes: > Modems which support MNP internally get a 20% boost in performance by > stripping start and stop bits from the data stream (MNP Service Class 3), but > this is not considered data compression. Actually, because of protocol overhead, the maximum benefit from MNP3 is about 9.8%; with MNP4 (and V.42 LAPM), you can acheive about a 22% increase. The maximum theoretical benefit, without protocol overhead, would be 25% (10/8), but you have to remember to subtract out for frame headers, FCS, flags, and average zero-bit insertion (average of 1 for every 63 bits). > MNP5 uses a type of LZW compression algorithm... MNP5 uses adaptive Huffman coding. V.42bis uses LZW. -- Toby Nixon, Principal Engineer | Voice +1-404-449-8791 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
kim@Software.Mitel.com (Kim Letkeman) (11/04/90)
In article <3182.27310BB8@zswamp.fidonet.org> root@zswamp.fidonet.org (Geoffrey Welsh) writes: | MNP5 uses a type of LZW compression algorithm, but its 'on the | fly' approach has some weaknesses, including the fact that MNP5 | will *lose ground* on well-compressed files (i.e. a .ZIP file | moves faster with MNP5 *dis*abled than with it enabled!). Well, my own experience contradicts this. With my old SmartTeam 2400bps modem I was very pleased that ZMODEM would tool along at an average speed of 134cps or so. My new ATI with MNP5 was actually able to maintain 274cps over a long .ZIP file. This kind of blows your argument up a bit. I've heard that "compress" files don't go as well, but my own experience is that "ZIP" files do ok. I certainly won't be turning off compression for ZMODEM transfers. -- Kim Letkeman kim@software.mitel.com uunet!mitel!spock!kim
kim@Software.Mitel.com (Kim Letkeman) (11/04/90)
w3In article <KIM.90Nov3234706@kim.Software.Mitel.com> kim@Software.Mitel.com (Kim Letkeman) writes: | In article <3182.27310BB8@zswamp.fidonet.org> root@zswamp.fidonet.org (Geoffrey Welsh) writes: | | | MNP5 uses a type of LZW compression algorithm, but its 'on the | | fly' approach has some weaknesses, including the fact that MNP5 | | will *lose ground* on well-compressed files (i.e. a .ZIP file | | moves faster with MNP5 *dis*abled than with it enabled!). | | Well, my own experience contradicts this. With my old SmartTeam | 2400bps modem I was very pleased that ZMODEM would tool along at an | average speed of 134cps or so. My new ATI with MNP5 was actually able ^^^ sorry ... 234cps. | to maintain 274cps over a long .ZIP file. This kind of blows your | argument up a bit. I've heard that "compress" files don't go as well, | but my own experience is that "ZIP" files do ok. I certainly won't be | turning off compression for ZMODEM transfers. -- Kim Letkeman kim@software.mitel.com uunet!mitel!spock!kim
root@zswamp.fidonet.org (Geoffrey Welsh) (11/05/90)
Kim Letkeman (kim@Software.Mitel.com ) wrote: > [re: my comment that MNP5 'loses ground' with pre-compressed files] >My new ATI with MNP5 was actually able to maintain 274cps over >a long .ZIP file. This kind of blows your argument up a bit. No, it proves only that you weren't paying attention to what I was saying. The boost that your ATI modem gives to transferring .ZIP files is due to the stripping of start and stop bits, which is done at MNP level 3, not MNP5 data compression. I think you'll find that the ATI, set to use MNP levels up to 4 but *not* MNP5 data compression will give better performance than the same modem & files with MNP5 data compression enabled. There will, of course, be files for which this does not hold, but I stand by my statement as a general rule. Hayes' Toby Nixon has corrected my comment about MNP5 being based on LZW (he pointed out that it uses the Huffman, not LZW, algorithm). I stand corrected on that point. >I certainly won't be turning off compression for ZMODEM transfers. Don't be so quick to make a rule of that. Try it! -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 MC Hammer, n. Device used to ensure firm seating of MicroChannel boards Try our new Bud 'C' compiler... it specializes in 'case' statements!
mussar@bcars53.uucp (G. Mussar) (11/06/90)
In article <KIM.90Nov4000953@kim.Software.Mitel.com> kim@Software.Mitel.com (Kim Letkeman) writes: >w3In article <KIM.90Nov3234706@kim.Software.Mitel.com> kim@Software.Mitel.com (Kim Letkeman) writes: > >| In article <3182.27310BB8@zswamp.fidonet.org> root@zswamp.fidonet.org (Geoffrey Welsh) writes: >| >| | MNP5 uses a type of LZW compression algorithm, but its 'on the >| | fly' approach has some weaknesses, including the fact that MNP5 >| | will *lose ground* on well-compressed files (i.e. a .ZIP file >| | moves faster with MNP5 *dis*abled than with it enabled!). >| >| Well, my own experience contradicts this. With my old SmartTeam >| 2400bps modem I was very pleased that ZMODEM would tool along at an >| average speed of 134cps or so. My new ATI with MNP5 was actually able > ^^^ > sorry ... 234cps. > >| to maintain 274cps over a long .ZIP file. This kind of blows your >| argument up a bit. Zmodem sends 10 bit async chars (1 start, 8 data and 1 stop). With non-MNP, these chars are sent between the modems as 10 bits each as well. This means that maximum performance is limited to 2400/10 = 240 chars/second (minus any Zmodem overhead). I think 234 is about right. When you use MNP class 3 and about, the data sent between the modems is synchronous (HDLC based). Each byte requires 8 bits rather than 10 (minus HDLC framing/CRC/control). This means taht class 3 performance will top out just under 2400/8 = 300 chars/second. Again, 274 is about right. The performance gain you've seen is not due to class 5 compression but due to class 3 sync transfer between the modems. What the original poster was saying was that by turning off LZW compression you should not see any degradation of your 274 cps (and might even see a slight increase). Give it a try. -- ------------------------------------------------------------------------------- Gary Mussar |Bitnet: mussar@bnr.ca | Phone: (613) 763-4937 BNR Ltd. | UUCP: ..uunet!bnrgate!bcars53!mussar | FAX: (613) 763-2626
tnixon@hayes.uucp (Toby Nixon) (11/06/90)
In article <KIM.90Nov3234706@kim.Software.Mitel.com>, kim@Software.Mitel.com (Kim Letkeman) writes: > | MNP5 uses a type of LZW compression algorithm, but its 'on the > | fly' approach has some weaknesses, including the fact that MNP5 > | will *lose ground* on well-compressed files (i.e. a .ZIP file > | moves faster with MNP5 *dis*abled than with it enabled!). > > Well, my own experience contradicts this. With my old SmartTeam > 2400bps modem I was very pleased that ZMODEM would tool along at an > average speed of 134cps or so. My new ATI with MNP5 was actually able > to maintain 274cps over a long .ZIP file. This kind of blows your > argument up a bit. I've heard that "compress" files don't go as well, > but my own experience is that "ZIP" files do ok. I certainly won't be > turning off compression for ZMODEM transfers. What you don't understand is that MNP4 (with MNP5 turned off!) can transfer 292 cps! That difference (from 292 down to 274 cps) is very likely caused by MNP5 _expanding_ your data. MNP3 and MNP4 (and LAPM) gain throughput by stripping the start and stop bit off each character; that by itself would increase the throughput of a 2400bps modem from 240cps (10 bit per character) to 300cps (8 bits per character), but you have to subtract out the protocol overhead leaving a capacity of 292cps for MNP4 or about 263cps for MNP3. -- Toby Nixon, Principal Engineer | Voice +1-404-449-8791 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
herrj@silver.ucs.indiana.edu (Jonathan R. Herr) (11/13/90)
In article <1990Nov5.172154.9486@bigsur.uucp> mussar@bcars53.uucp (G. Mussar) writes: >Zmodem sends 10 bit async chars (1 start, 8 data and 1 stop). With non-MNP, >these chars are sent between the modems as 10 bits each as well. This means >that maximum performance is limited to 2400/10 = 240 chars/second (minus any >Zmodem overhead). I think 234 is about right. >Gary Mussar |Bitnet: mussar@bnr.ca Well, I hate to disagree (okay, I like to) but at 2400 bps, my STAR modem *regularly* transfers at rates in excess of 250 cps on ZIP'ed files from another 2400 bps modem. Neither of us run MNP anything. And this is using Zmodem. However, it does seem to degrade as the files get larger (ie. > 120K). This is also with only this one particular BBS. It seems that the other BBS's around town carry a lot of line noise or suffer the effects of transferring through a network before getting to the modem (at least those are the only reasons that I can think of). I did, on one occassion only, achieve 260 cps transferring a large text file (ie. ~200K). Is this simply a fluke in the protocol or are our modems working faster than normal? Jonathan R. Herr | Don't wait to see me. Send e-mail. I don't herrj@silver.ucs.indiana.edu| always make it to campus but always get home. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I'd clone myself if I could and get twice as much done in a single day.