Harvey_Taylor@mindlink.UUCP (Harvey Taylor) (03/08/91)
In <3835.27d649d6@hayes.uucp>, tnixon@hayes.uucp (Toby Nixon) writes: | |In article <1991Mar6.165542.10140@cs.mcgill.ca>, storm@cs.mcgill.ca |(Marc WANDSCHNEIDER) writes: | | [re V.32 vs V.32bis] | |> What sort of throughput can one expect (theoretically I suppse) |> using a V.32bis modem with V.42bis compression...? | |If you accept that V.42bis achieves up to 4-to-1 compression on text |data, you could expect to see up to 57,600bps throughput with |V.42bis over V.32bis. This is quite dependent on the modem |implementation. Many vendors are sticking with a maximum 38,400bps |interface rate, and using the increased modulation speed of V.32bis |to increase the types of data that actually acheive 38,400bps |throughput, rather than trying to push for more. V.32bis also |increases the throughput of uncompressible data and of synchronous |transmissions. | <curmudgeon mode on> It really bugs me to see companies advertising 57.6K bps throughput when they know damn well that the data types which allow 4:1 compression are so rare, as to make their ad misleading. <curmudgeon mode off> <wishful thinking mode on> What I would like to see is a thorough comparison of these transmission protocols and compression techniques with varying sorts of data. ie. the layout would look something like: ------------------------------------------------------------------- TRANSMISSION COMPRESSION DATA TYPE THRUPUT THRUPUT PROTOCOL TECHNIQUE (unc=uncompressed) THEORETICAL ACTUAL (com=compressed*) BPS BPS ------------------------------------------------------------------- HST MNP5 unc ascii HST MNP5 unc binary HST MNP5 unc sound samples HST MNP5 unc video samples HST MNP5 com ascii HST MNP5 com binary HST MNP5 com sound samples HST MNP5 com video samples ------------------------------------------------------------------- HST V.42 unc ascii HST V.42 unc binary HST V.42 unc sound samples HST V.42 unc video samples HST V.42 com ascii HST V.42 com binary HST V.42 com sound samples HST V.42 com video samples ------------------------------------------------------------------- HST V.42bis unc ascii HST V.42bis unc binary HST V.42bis unc sound samples HST V.42bis unc video samples HST V.42bis com ascii HST V.42bis com binary HST V.42bis com sound samples HST V.42bis com video samples ------------------------------------------------------------------- And so on for PEP, V.32, V.32bis, Hayes or whatever.Clearly this is an evaluation which would require serious dedication. The compression and transmission protocols can be extended, as can the data types. Another source of complexity [just ask Telebit, heh heh] is the array of S-Register settings available. I suppose one could add another couple of categories NOISY LINE, CLEAN LINE; LONG DATA PATH, SHORT DATA PATH.# You'll notice that the number of datapoints has now become: Trans_Protocols * Comp_Protocols * Data_Types * Line_Types * Path_Lengths Note: * name your favourite archivers: zoo, lharc, zip, compress etc # ie a local call or one where your data is going across the country, up to a satellite & thru a cable. So is anybody [magazine/company] upto the challenge? <wishful thinking mode off> -het "Build it right. Build it stout. Out of things we know about." Harvey Taylor Meta Media Productions uunet!van-bc!rsoft!mindlink!Harvey_Taylor a186@mindlink.UUCP
Mike_Benna@mindlink.UUCP (Mike Benna) (03/08/91)
> Harvey Taylor@mindlink.UUCP writes: > > What I would like to see is a thorough comparison of these transmission > protocols and compression techniques with varying sorts of data. Actually there are many more considerations than just those you have investigated in your calculation (for example are you using Xmodem, Zmodem, UUCP-G, etc.) So many in fact that it is far easier to learn what the various protocols do and to use that information to determine what type of throughputs to expect. After that, TEST IT in your application and see what you get before putting down the money. Marketing people will always try to hype a product (especially in the computer industry) - it is up to the consumer to understand what he/she is buying. As for answering the original question, you should expect to get 1.5 times the throughput from a V.32bis modem as you used to get from a V.32 modem. On pre-compressed data with V.42 error control (LAPM in particular) you should see about 1124 cps from a V.32 modem and 1686 cps from a V.32bis modem. -- ---> Mike Benna, Vancouver, B.C., Canada MindSpan Technologies Corp. - Video Game Design and Development EMAIL: Mike_Benna@mindlink.UUCP or ...!van-bc!rsoft!mindlink!Mike_Benna
pplaceway@bbn.com (Paul Placeway) (03/10/91)
Harvey_Taylor@mindlink.UUCP (Harvey Taylor) writes:
< <curmudgeon mode on>
< It really bugs me to see companies advertising 57.6K bps throughput
< when they know damn well that the data types which allow 4:1 compression
< are so rare, as to make their ad misleading.
< <curmudgeon mode off>
Microcom is guilty of this (MNP5 won't do anything like 2:1 average),
but you really can get 4:1 *average* compression out of the newer
techniques (both LZ-ish and statistical). (The best of statistical or
dictionary (LZ) methods are around 5:1 for USENet batches these days.)
As a brain-dead test a while ago, I ran script(1), and then did about
2 hours compile/edit/test work over the phone, ended the script, and
did "compress -v typescript". Guess what: 3.9:1 compression average.
V.42bis uses a better method than 16-bit LZW, so it should do better
still. Also note that this is with an ANSI-style terminal (Macintosh
Kermit :-)), and the ANSI sequences are kinda verbose (although they
make up for it by being parametric), so your mileage may vary, but
probably not by much.
Of course to actually see 4:1 average compression, you have to be able
to get better than 4:1 throughput on the "good" sequences, which means
a serial connection at better than 4 times the underlying connection
speed or big buffers in the modem and 4 times the underlying speed (4
* 14.4k == 57.6 kbps for v.32bis, more like 115.2 kbps or better for
V.FAST).
Don't confuse MNP5 hype with v.42bis hype. The former is generally
untrue, but the latter isn't far off.
-- Paul Placeway
If you thought decoding a 512-point constellation is hard, try
decoding human speech!