Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!haven.umd.edu!mimsy!dftsrv!heawk1!hoepfner From: hoepfner@heawk1.gsfc.nasa.gov (Patrick Hoepfner) Newsgroups: comp.sys.mac.comm Subject: Re: Summary of 9600 V.32 bis modem info Message-ID: Date: 17 Jun 91 03:28:50 GMT References: <676362366.22@egsgate.FidoNet.Org> Sender: news@dftsrv.gsfc.nasa.gov Organization: NASA/Goddard Space Flight Center Lines: 47 Doug.Siebert@f98.n250.z1.FidoNet.Org (Doug Siebert) writes: >In article <6937@husc6.harvard.edu> conrad@popvax.uucp (M20400@c.nobili) >writes: >> >>I don't know much about PeeCee compression formats. Are they so inefficient >>as to allow "116 % efficiency typical"? I had pointed out that if the same >>compression algorithm were used on the files as V.42bis would use if they >>were not compressed, then one should see 1:1 compression ratios on clean >lines... ;-) >>I tend to use GNU compress on UNIX, MacOS, and DOS, so I don't know about >>the ones mentioned above.... >I'm no expert on modems, but my own personal theory on compressed files being >sent with > 100% efficiency is that the start/stop bits are eliminated for >the most part, allowing potential gains (if all such bits were removed, which >would be impractical) of 25%, leading to efficencies in excess of 120% Some >correct me if I'm wrong (like I have to ask for this! :-) ) Just to add my 2 cents... The compression routines that are used on your computer Un*x compress, PC arc, and Mac StuffIt (to name a few), basically do the same as MNP5 or V.42bis. The only difference is that MNP5 (up to 2 to 1 compression) and V.42bis (up to 4 to 1 compression) do the compression on the fly. They don't require you to compress the program on your end and have the person on the other end uncompress them (also meaning the person on the other end doesn't have to worry about having the correct uncompression program - just the correct modem). Because these 'on the fly' compression techniques have to worry about working quickly, they probably won't ever keep up with the stand alone applications. But then again, you don't have to spend your time compressing and un- compressing them. The 2x1 and 4x1 compression is idealized. And significant compression can only be had on text files (with lots of repeated strings). If the file is already compressed the MNP5 compression will actually make the file longer. V.42bis looks to see if it is doing any good and will not compress a file if the resultant file is getting bigger. (I have read that MNP5 can actually crash the link if the file is already compressed). The answer is the 2x1 and 4x1 compression is idealized and will never be realized in real life situations, but text file will transfer significantly faster with MNP5 or V.42bis than without (and V.42bis is not only faster than MNP5, but also safer). -- Pat --------------------------------------> hoepfner@heasfs.gsfc.nasa.gov