Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!umich!sharkey!rjf001!mudos!mju From: mju@mudos.ann-arbor.mi.us (Marc Unangst) Newsgroups: comp.dcom.modems Subject: Re: V.42/V.42bis vs. MNP4/MNP5 (WAS Re: V.42 questions on T2500 -- H Message-ID: Date: 25 Jun 91 16:47:52 GMT References: <1991Jun24.175643.7733@hou.amoco.com> Organization: The Programmer's Pit Stop, +1 313 665 2832 Lines: 27 zjdg11@hou.amoco.com (Jim Graham) writes: > So, what am I missing here? I'm honestly curious as to why so many people > seem to talk about the evils of V.42bis on file xfers when I see such an > improvement....that is, btw, measured stats on BBSs and from DSZ. (The stats Because they don't know what they're talking about. MNP5, which is the MNP implimentation of compression, tries to compress already-compressed data, and ends up making the data bigger, meaning you usually see a throughput DROP when you enable MNP5 on a connection that's sending compressed data. V.42bis, on the other hand, doesn't bother compressing the data if it ends up bigger after compression than it was before -- sort of like compress(1) without the -f switch. Anyway, people who speak the evils of using V.42bis on compressed file transfers are thinking that it does the same bad things that MNP5 does, which is not true. Just as some additional data points: I regularly get 1120cps or so using Zmodem to transfer .ZIP files over a 9600/V.32/V.42/V.42bis connection. On the other hand, UUCP throughput (sending compressed news batches over a V.32 connection) jumped from about 750cps to about 990cps when I turned off MNP5 and only used MNP4. -- Marc Unangst | mju@mudos.ann-arbor.mi.us | "Bus error: passengers dumped" ...!hela!mudos!mju |