time@ice.com (Tim Endres) (05/31/91)
In article <6913@husc6.harvard.edu>, conrad@popvax.uucp (M20400@c.nobili) writes: > Hmmm. Your "_real_ throughput of about 22K" on "files that were already com- > pressed" seems questionable. I believe your modem supports a maximum link rate > of 9,600 bps. So with a pair of such modems, connected at 9,600 bps and using > V.42bis compression your could _hope_ for a maximum throughput of 38,400 bps if > you believed the manufacturers' claims of 4:1 compression for V.42bis.... You > would probably have to "cook" a file to get anything close to this (i.e., make > a big file of just spaces, or the letter x or something). Consensus seems to > be that ratios of 2.5:1 to 2.7:1 are more usual. Your claimed throughput works > out to a ratio of 2.3:1, which is pretty close to what one should expect for > "normal" compressible text. On stuff that was _already_ compressed (as tightly > as V.42bis can compress things) you will see "real throughput" of _no greater > than_ 9,600 bps! No (further) compression possible = 1:1 compression ratio => > throughput of 1 X link rate = 9,600 bps.... Remember that V.32 (from what I remember) does not need the framing bits that 2400 baud uses, giving something on the order of a 20% increase in real throughput. If someone knows the details about this, please post. ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uupsi!ice.com!time 8840 Main Street | Voice FAX Whitmore Lake MI. 48189 | (313) 449 8288 (313) 449 9208
root@zswamp.uucp (Geoffrey Welsh) (06/02/91)
In a letter to All, Tim Endres (time@ice.com ) wrote: >Remember that V.32 (from what I remember) does not need the >framing bits that 2400 baud uses, giving something on the >order of a 20% increase in real throughput. >If someone knows the details about this, please post. It has nothing to do with the nature of V.32; V.22bis (2400 bps) doesn't need the framing bits any more than V.32 does, but they're left in there because the asynchronous protocol between the computers and their respective modems requires it. More sophisticated modems, with error-correcting protocols, have the internal intelligence and computing power to make whatever adjustments are necessary to take advantage of the fact that 20% of the data coming in the modem's RS-232 port is completely redundant. If someone could be bothered to impliment MNP3 and 4 on a Bell 103J modem, I'm sure that you could get the same relative speed boost at 300 bps. -- Geoffrey Welsh - Operator, Izot's Swamp BBS (FidoNet 1:221/171) root@zswamp.uucp or ..uunet!watmath!xenitec!zswamp!root 602-66 Mooregate Crescent, Kitchener, ON, N2M 5E6 Canada (519)741-9553 "He who claims to know everything can't possibly know much" -me
zjdg11@hou.amoco.com (Jim Graham) (06/03/91)
First, let me say this --- I don't speak for my employer here....all of these comments are based on what I've seen with my own modem, at home, and with personal use. (standard disclaimer, in other words) In article <6913@husc6.harvard.edu>, conrad@popvax.uucp (M20400@c.nobili) writes: > So with a pair of such modems, connected at 9,600 bps and using > V.42bis compression your could _hope_ for a maximum throughput of 38,400 bps > if > you believed the manufacturers' claims of 4:1 compression for V.42bis.... I've got a Telebit T2500, which of course, has V.32 and V.42/V.42bis. With this, when I connect to V.32/V.42/V.42bis modems, and assuming a clean phone line (obviously, re-transmissions over a lousy line will reduce throughput), my brain-dead serial link, which thinks 19.2 is the end of the world, is the bottelneck. Now, when I connect to a 2400/V.42/V.42bis modem, my eyes see roughly the same throughput as a v.32/nothing link --- roughly 4:1 compression (in that area, at least). Now, for file transfers (each case refers to ZIPped [with implosion] files, Zmodem xfer w/o Zmodem compression, and no errors) I typically see the following type stats: a) no V.42: 95 -- 97 % efficiency b) V.42/V.42bis: 116 % efficiency typical, 127 % efficiency max. now, I had heard such claims for a long time, and never believed them...until I started seeing the results...with remarkable consistency. These figures, btw, remain constant among 3 different software packages.... > You > would probably have to "cook" a file to get anything close to this (i.e., > make > a big file of just spaces, or the letter x or something). No, these were real files. They vary from ZIPed GIFs, ZIPed text, ZIPed binaries, and combinations of the above. > Consensus seems to > be that ratios of 2.5:1 to 2.7:1 are more usual. Your claimed throughput > works > out to a ratio of 2.3:1, which is pretty close to what one should expect for > "normal" compressible text. ok --- why do I consistently see so much higher throughput than this? (this is intended as a serious, not sarcastic, question.) As another example, when on a different terminal, which did support 38.4 on the serial link, and a different V.32/V.42/V.42bis modem (which also did 38.4 serial), I can't say for sure that the throughput looked just like 38.4...not having seen exactly that speed like I have 9.6 so often, but it was ** WELL ** beyond 19.2 (2:1). > On stuff that was _already_ compressed (as tightly as V.42bis can compress > things) and that, folks, is the key phrase.... text is far, far from being compressed as much as V.42bis can compress it.... :-) Now, having said all that --- I do see considerably less throughput on noisy phone lines (the kind where you can hear the impulse noise while the modems train....really bad). That's where all the statements I'm disagreeing with are absolutely true. But, if you DO have a good line..... Again, this is all based on what I see with my own eyes. I didn't believe a word of this until I did see it. No company (including my employer) is in any way compensating me or prompting me to make these remarks. --jim ------------------------------------------------------------------------------ Share and Enjoy! (Sirius Cybernetics Corporation, complaints division) 73, de n5ial Internet: jdgraham@hou.amoco.com grahj@gagme.chi.il.us Amateur Radio: TCP/IP: jim@n5ial.ampr.org (44.72.47.193) Packet: bbs went qrt....no new bbs yet ------------------------------------------------------------------------------
andyb@stb.info.com (Andy B.) (06/03/91)
I just missed this summary. Did anyone happen to save it? Thanks! Andy -- If it's not broken...your girlfriend will get bored with it anyway.
rdippold@cancun.qualcomm.com (Ron Dippold) (06/04/91)
In article <1CE00001.gxxd0m@tbomb.ice.com> time@ice.com writes: > >In article <6913@husc6.harvard.edu>, conrad@popvax.uucp (M20400@c.nobili) writes: >> Hmmm. Your "_real_ throughput of about 22K" on "files that were already com- >> pressed" seems questionable. I believe your modem supports a maximum link rate >> of 9,600 bps. So with a pair of such modems, connected at 9,600 bps and using >Remember that V.32 (from what I remember) does not need the framing >bits that 2400 baud uses, giving something on the order of a 20% increase >in real throughput. If someone knows the details about this, please >post. Expected throughput on a V.32 modem with V.42bis is about 1100 cps. Some are slightly slower or faster, but that has always been my experience with ZIPed and ARJed files. -- Standard disclaimer applies, you legalistic hacks. | Ron Dippold
conrad@popvax.uucp (M20400@c.nobili) (06/04/91)
-- Again, note comp.dcom.modems in the Followup-To: field -- most appropriate. <1991Jun2.233826.29382@hou.amoco.com> zjdg11@hou.amoco.com (Jim Graham) writes: ><6913@husc6.harvard.edu>, conrad@popvax.uucp (M20400@c.nobili) writes: >> So with a pair of such modems, connected at 9,600 bps and using >> V.42bis compression you could _hope_ for a maximum throughput of 38,400 bps >> if you believed the manufacturers' claims of 4:1 compression for V.42bis.... >I've got a Telebit T2500, which of course, has V.32 and V.42/V.42bis. With ^^^^^^^^^^^^^^^^^^^^^^^^ >this, when I connect to V.32/V.42/V.42bis modems, and assuming a clean phone >line (obviously, re-transmissions over a lousy line will reduce throughput), >my brain-dead serial link, which thinks 19.2 is the end of the world, is the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >bottelneck. Now, when I connect to a 2400/V.42/V.42bis modem, my eyes see ^^^^^^^^^^^ >roughly the same throughput as a v.32/nothing link --- roughly 4:1 >compression (in that area, at least). A couple of things so far. You've got a Telebit T2500. I had one too. Your brain-dead _modem_ thinks 19.2 is the end of the world. (I've got my flame- retardant unders on in case any of you think that I _really_ think that T2500s are brain-dead....) You should use more accurate measuring tools. I hope you're not an engineer! (Oops -- didn't have room for the ;-) !) Ok, now comes some stuff I really am not sure I follow. Beware. I may extract the wrong sense from this confusion, but I will try.... Background for c.d.m people: This started in c.s.m.c, but it was really just modem stuff, so I sent it here (sorry now, I guess). Someone had made a claim of "_real_ throughput of about 22K" on "files that were already compressed" with a V.32 & V.42bis modem, and I didn't want people to expect magic. It turned out that the person was transferring ".sit.hqx" files. So I explained lots of the issues, and that although ".sit" files are compressed pretty efficiently, ".hqx" files are by necessity not so. Which makes the 22K throughput _not_ really a figure for compressed data. I was a little puzzled because 22K / 9,600 = 2.3, which seems like a very good compression ratio for a ".sit.hqx" file. I had thought it would be lower than that. I was hoping for more data from others. I explained why this person really _did_ have a 9,600 bps modem.... (Note that I do believe in data compression, and am squeezing about 35Kbps through my pair of USRobotics Courier V.32bis modems even (especially?) as I type....) >Now, for file transfers (each case refers to ZIPped [with implosion] files, >Zmodem xfer w/o Zmodem compression, and no errors) I typically see the >following type stats: > > a) no V.42: 95 -- 97 % efficiency > b) V.42/V.42bis: 116 % efficiency typical, > 127 % efficiency max. > >now, I had heard such claims for a long time, and never believed them...until >I started seeing the results...with remarkable consistency. These figures, >btw, remain constant among 3 different software packages.... >> You would probably have to "cook" a file to get anything close to this (i.e. >> make a big file of just spaces, or the letter x or something). By "this" I mean 4:1 compression ratios, not the paltry, believable ones above! >No, these were real files. They vary from ZIPed GIFs, ZIPed text, ZIPed >binaries, and combinations of the above. 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 com- pression 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.... >> Consensus seems to be >> that ratios of 2.5:1 to 2.7:1 are more usual. Your claimed throughput works >> out to a ratio of 2.3:1, which is pretty close to what one should expect for >> "normal" compressible text. This is just the rough sense that I have gleaned from my own observations and stuff I see on c.d.m. I was hoping that we could get a better handle on these figures in c.d.m.... I guess I also have a sort of morbid curiosity about the ratios that you get, Geoffrey, with your one-megabyte files of nulls.... >ok --- why do I consistently see so much higher throughput than this? (this >is intended as a serious, not sarcastic, question.) As another example, when >on a different terminal, which did support 38.4 on the serial link, and a >different V.32/V.42/V.42bis modem (which also did 38.4 serial), I can't say >for sure that the throughput looked just like 38.4...not having seen exactly >that speed like I have 9.6 so often, but it was ** WELL ** beyond 19.2 (2:1). This is the throughput that you "see"? What do the bits look like? ;-) Also, am I correct when I read this to mean that you _aren't_ using a T2500 here -- a necessity for "38.4 on the serial link"? Or are you being deceived by more than your eyes? The mention of a _single_ different modem makes me wonder.... >> On stuff that was _already_ compressed (as tightly as V.42bis can compress >> things) This is the kind of data that the original "_real_ throughput of about 22K" was _by definition_ not talking about.... >and that, folks, is the key phrase.... text is far, far from being compressed >as much as V.42bis can compress it.... :-) Yes, exactly. Nor, apparently (if we are to believe that the guy with the "_real_ throughput of about 22K" had a better yardstick than you have (don't have?)) are ".sit.hqx" files. Note that ".sit" files have often been compressed using LZW and should be about as efficient/inefficient as V.42bis. (Right?) I am unsure whether BinHex (produces ".hqx" files) expands ".sit" files to as much as the 2.3X size that would seem to be implied by the original figures.... My network traffic seems to be compressible by anywhere from 1.8:1 to 2.5:1.... I still want numbers on _just how much_ "normal text" can be compressed by V.42bis modems.... Were the numbers I tossed out a fair impression from c.d.m? >Now, having said all that --- I do see considerably less throughput on noisy >phone lines (the kind where you can hear the impulse noise while the modems >train....really bad). That's where all the statements I'm disagreeing with >are absolutely true. But, if you DO have a good line..... I think you actually agree with what I was saying -- you just weren't sure what I was saying.... >Again, this is all based on what I see with my own eyes. I didn't believe a >word of this until I did see it. No company (including my employer) is >in any way compensating me or prompting me to make these remarks. Really, consider some _measurements_! And I _hope_ nobody is compensating you for most of those remarks! ;-) (Sorry, I guess I am just in a frisky mood!) > --jim > > >------------------------------------------------------------------------------ >Share and Enjoy! (Sirius Cybernetics Corporation, complaints division) >73, de n5ial > >Internet: jdgraham@hou.amoco.com > grahj@gagme.chi.il.us >Amateur Radio: > TCP/IP: jim@n5ial.ampr.org (44.72.47.193) > Packet: bbs went qrt....no new bbs yet >------------------------------------------------------------------------------ +---- C o n r a d C . N o b i l i ----+ | | | Harvard University | Internet: conrad@harvarda.harvard.edu | | Office for Info. Tech. | conrad@popvax.harvard.edu | | Information Services | BITNET: CONRAD AT HARVARDA | | Technical & User Services | CONRAD AT HARVSPHB | | 1730 Cambridge Street | voice: (617) 495-8554 | +---- Cambridge, MA 02138 | fax: (617) 495-0715 ----+
dsiebert@icaen.uiowa.edu (Doug Siebert) (06/04/91)
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 com- >pression 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! :-) )