Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!van-bc!rsoft!mindlink!a186 From: Harvey_Taylor@mindlink.UUCP (Harvey Taylor) Newsgroups: comp.dcom.modems Subject: Testing actual throughtputs Message-ID: <5051@mindlink.UUCP> Date: 7 Mar 91 18:05:57 GMT Organization: MIND LINK! - British Columbia, Canada Lines: 90 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. | 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. 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? -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