s902114@minyos.xx.rmit.oz.au (Zen) (02/11/91)
Has anyone out in netland compiled a list of File transfer protocols and there respective speeds? I don not have the facilities to do my own tests. If anyone out there actually has FIGURES specific for different systems, i am using a 2400 baud modem with NO error correction. -- _____ Two elephants fell off a cliff. Boom Boom. // // __ // // / \ I\ I for a good time call // // (-- I \I alias s902114@minyos.xx.rmit.oz.au // // \__/ I I Stuart Bishop or zen@phoenix.pub.uu.oz.au // ((___________________________________________________________________// -- _____ Two elephants fell off a cliff. Boom Boom. // // __ //
rdippold@maui.qualcomm.com (Ron Dippold) (02/19/91)
In article <1991Feb11.133727.1160@minyos.xx.rmit.oz.au> s902114@minyos.xx.rmit.oz.au (Zen) writes: >Has anyone out in netland compiled a list of File transfer protocols and >there respective speeds? I don not have the facilities to do my own tests. > >If anyone out there actually has FIGURES specific for different systems, > >i am using a 2400 baud modem with NO error correction. There are over 50 protocols, I don't think there are figures on ALL of them. However, if you want figures on the most common ones... HyperP - 300 cps (ZIPped file) Puma - 236 cps (ZIPped file) Zmodem (MT) - 234 cps ZMODEM - 230 cps YMODEM - 221 cps XMODEM - 208 cps KERMIT - 140 cps SEALINK - 218 cps I should note that Puma will perform much faster if you are sending an uncompressed file, as it has a rudimentary packer, as does JMODEM. The fastest protocol, hands down, is HyperP, it's packing is incredible, even with an alread ZIPped file. Unfortunately, it has a nasty tendency to freeze if the RX and TX don't synchronize exactly right, so you won't see it on many boards. Also note that KERMITs are highly variable and depend on your version and the version and mainframe that you are sending to. All rates are for 2400 baud, given in cps (characters per second).
kdq@demott.com (Kevin D. Quitt) (02/19/91)
In article <1991Feb18.203344.1433@qualcomm.com> rdippold@maui.qualcomm.com (Ron Dippold) writes: >In article <1991Feb11.133727.1160@minyos.xx.rmit.oz.au> s902114@minyos.xx.rmit.oz.au (Zen) writes: >>Has anyone out in netland compiled a list of File transfer protocols and >>there respective speeds? I don not have the facilities to do my own tests. >> >>If anyone out there actually has FIGURES specific for different systems, >> >>i am using a 2400 baud modem with NO error correction. > >There are over 50 protocols, I don't think there are figures on ALL of them. >However, if you want figures on the most common ones... > > HyperP - 300 cps (ZIPped file) > Puma - 236 cps (ZIPped file) > Zmodem (MT) - 234 cps > ZMODEM - 230 cps > YMODEM - 221 cps > XMODEM - 208 cps > KERMIT - 140 cps > SEALINK - 218 cps > >I should note that Puma will perform much faster if you are sending an >uncompressed file, as it has a rudimentary packer, as does JMODEM. The >fastest protocol, hands down, is HyperP, it's packing is incredible, even >with an alread ZIPped file. Unfortunately, it has a nasty tendency to >freeze if the RX and TX don't synchronize exactly right, so you won't see it >on many boards. I consider it misleading, at best, and dishonest, at worst, to indicate the speed of the modem by examining how many pre-compressed bytes per second are transferred. I have images that compress 100-to-1, and kermit sends them at about 140 compressed cps, or about 14000 cps, compared to HyperP. Since a lot of traffic cannot be compressed, it is more important to give the underlying transfer speed, and *then* start bragging about the wonderfulnees of the compression. And please make sure that data that is already compressed doesn't slow down the transfer (like MNP-5 does). -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last
rdippold@maui.qualcomm.com (Ron Dippold) (02/20/91)
In article <1991Feb19.021725.14317@demott.com> kdq@demott.com (Kevin D. Quitt) writes: >In article <1991Feb18.203344.1433@qualcomm.com> rdippold@maui.qualcomm.com (Ron Dippold) writes: >> >>There are over 50 protocols, I don't think there are figures on ALL of them. >>However, if you want figures on the most common ones... >> [stats] >> >>I should note that Puma will perform much faster if you are sending an >>uncompressed file, as it has a rudimentary packer, as does JMODEM. The >>fastest protocol, hands down, is HyperP, it's packing is incredible, even >>with an alread ZIPped file. Unfortunately, it has a nasty tendency to >>freeze if the RX and TX don't synchronize exactly right, so you won't see it >>on many boards. > > I consider it misleading, at best, and dishonest, at worst, to >indicate the speed of the modem by examining how many pre-compressed >bytes per second are transferred. I have images that compress 100-to-1, >and kermit sends them at about 140 compressed cps, or about 14000 cps, >compared to HyperP. > > Since a lot of traffic cannot be compressed, it is more important to >give the underlying transfer speed, and *then* start bragging about the >wonderfulnees of the compression. And please make sure that data that >is already compressed doesn't slow down the transfer (like MNP-5 does). I always assume compressed files, because I have yet to see a bulletin board system that doesn't archive their files. All this wonderful stuff about compression becomes worthless when most files are already compressed. And if you want to transfer VAX to PC, use ZOO. Why would you NOT compress before transferring? Finally, every file is different. I am not about to list the different protocol speeds for each protocol for text, graphics, GIF, executable, etc. If you wish to do that, fine, but a pre-compressed file provides a good common point of comparison. I see nothing "misleading" or "dishonest" about it. I'm suprised you didn't indicate that you were "outraged," that common expression of mortal indignation.
ralf+@cs.cmu.edu (Ralf Brown) (02/20/91)
In article <1991Feb18.203344.1433@qualcomm.com> rdippold@maui.qualcomm.com (Ron Dippold) writes: }In article <1991Feb11.133727.1160@minyos.xx.rmit.oz.au> s902114@minyos.xx.rmit.oz.au (Zen) writes: } } HyperP - 300 cps (ZIPped file) } Puma - 236 cps (ZIPped file) } Zmodem (MT) - 234 cps } ZMODEM - 230 cps } }I should note that Puma will perform much faster if you are sending an }uncompressed file, as it has a rudimentary packer, as does JMODEM. The As does Zmodem (all three do run-length encoding). The Zmodem protocol also allows for 12-bit LZW compression, though I don't know of anybody implementing it. }fastest protocol, hands down, is HyperP, it's packing is incredible, even }with an alread ZIPped file. Unfortunately, it has a nasty tendency to Is that speed figure by the wall clock or using the built-in speed display? The Zmodem in Telix is notorious for over-inflating throughput, particularly on short files. Also, that ZIP file you used must have had huge numbers of tiny files, resulting in much of the file being uncompressed headers, because not even ARJ manages to compress the typical ZIP file by more than 2-3%. -- {backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/3.1 BITnet: RALF%CS.CMU.EDU@CMUCCVMA AT&Tnet: (412)268-3053 (school) FAX: ask DISCLAIMER? Did | It isn't what we don't know that gives us trouble, it's I claim something?| what we know that ain't so. --Will Rogers
rdippold@maui.qualcomm.com (Ron Dippold) (02/21/91)
In article <1991Feb20.040652.26925@cs.cmu.edu> ralf+@cs.cmu.edu (Ralf Brown) writes: >In article <1991Feb18.203344.1433@qualcomm.com> rdippold@maui.qualcomm.com (Ron Dippold) writes: >}In article <1991Feb11.133727.1160@minyos.xx.rmit.oz.au> s902114@minyos.xx.rmit.oz.au (Zen) writes: >} >} HyperP - 300 cps (ZIPped file) >} Puma - 236 cps (ZIPped file) >} Zmodem (MT) - 234 cps >} ZMODEM - 230 cps >} >}fastest protocol, hands down, is HyperP, it's packing is incredible, even >}with an alread ZIPped file. Unfortunately, it has a nasty tendency to > >Is that speed figure by the wall clock or using the built-in speed display? >The Zmodem in Telix is notorious for over-inflating throughput, particularly >on short files. Also, that ZIP file you used must have had huge numbers of >tiny files, resulting in much of the file being uncompressed headers, because >not even ARJ manages to compress the typical ZIP file by more than 2-3%. > No, believe it or not, that ZIP file consisted of only 10 files and was about 200K long. I timed it by the wall clock and by its internal display. It did slightly inflate the cps (it claimed 310 cps). But with every ZIPped file I have sent with HyperP, I get a 280 to 310 cps throughput! That is what impressed me, as I am also a big ARJ fan (Jung has V1.00 out, BTW). I did not believe it at first, because I knew of no disk-based utility that could compress a ZIP file that much! I would really like to know what compression scheme these guys are using... This protocol would spread like wildfire if it was more reliable.
Ralf.Brown@B.GP.CS.CMU.EDU (02/23/91)
In article <1991Feb20.221117.13560@qualcomm.com>, rdippold@maui.qualcomm.com (Ron Dippold) wrote: }In article <1991Feb20.040652.26925@cs.cmu.edu> ralf+@cs.cmu.edu (Ralf Brown) writes: }>In article <1991Feb18.203344.1433@qualcomm.com> rdippold@maui.qualcomm.com (Ron Dippold) writes: }>}In article <1991Feb11.133727.1160@minyos.xx.rmit.oz.au> s902114@minyos.xx.rmit.oz.au (Zen) writes: }>} }>} HyperP - 300 cps (ZIPped file) }> }>Is that speed figure by the wall clock or using the built-in speed display? } }No, believe it or not, that ZIP file consisted of only 10 files and was about }200K long. I timed it by the wall clock and by its internal display. It did }slightly inflate the cps (it claimed 310 cps). But with every ZIPped file I }have sent with HyperP, I get a 280 to 310 cps throughput! That is what Since the docs state that compression is disabled on already-compressed files, here is my conjecture: HyperP switches the modems into synchronous mode, thus using only 8 bits per character instead of 10. This yields a raw throughput of 300cps, less any protocol overhead (MNP4/5 use about 15 cps, which is why Ymodem-G gets about 283/284 cps after subtracting its own small overhead). Have you tried HyperP on an MNP link or with compression turned off? If my conjecture is correct, it will fail on an MNP link and show little or no speed difference with compression off (on ZIP files, that is). -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: 1:129/3.1 Disclaimer? | Plausible impossibilities should be preferred to What's that? | unconvincing possibilities. -- Aristotle, Poetics 24 -- {backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/3.1 BITnet: RALF%CS.CMU.EDU@CMUCCVMA AT&Tnet: (412)268-3053 (school) FAX: ask DISCLAIMER? Did | It isn't what we don't know that gives us trouble, it's I claim something?| what we know that ain't so. --Will Rogers
rdippold@maui.qualcomm.com (Ron Dippold) (02/27/91)
In article <27c66ffc@ralf> Ralf.Brown@B.GP.CS.CMU.EDU writes: >In article <1991Feb20.221117.13560@qualcomm.com>, rdippold@maui.qualcomm.com (Ron Dippold) wrote: >}In article <1991Feb20.040652.26925@cs.cmu.edu> ralf+@cs.cmu.edu (Ralf Brown) writes: >}>In article <1991Feb18.203344.1433@qualcomm.com> rdippold@maui.qualcomm.com (Ron Dippold) writes: >}>}In article <1991Feb11.133727.1160@minyos.xx.rmit.oz.au> s902114@minyos.xx.rmit.oz.au (Zen) writes: >}>} >}>} HyperP - 300 cps (ZIPped file) >}> >}>Is that speed figure by the wall clock or using the built-in speed display? >} >}No, believe it or not, that ZIP file consisted of only 10 files and was about >}200K long. I timed it by the wall clock and by its internal display. It did >}slightly inflate the cps (it claimed 310 cps). But with every ZIPped file I >}have sent with HyperP, I get a 280 to 310 cps throughput! That is what > >Since the docs state that compression is disabled on already-compressed files, >here is my conjecture: HyperP switches the modems into synchronous mode, >thus using only 8 bits per character instead of 10. This yields a raw >throughput of 300cps, less any protocol overhead (MNP4/5 use about 15 cps, >which is why Ymodem-G gets about 283/284 cps after subtracting its own small >overhead). > >Have you tried HyperP on an MNP link or with compression turned off? If my >conjecture is correct, it will fail on an MNP link and show little or no >speed difference with compression off (on ZIP files, that is). Well, when I was testing it, I was running it on a 2400 bps modem without MNP4 or 5 capability. Now I've acquired a USR DS (evil laugh), so I'll have to try it to see what it does when the USR is in maximum speed mode. I'd play around with it more, but it freezes so often on synchronization that it's probably not worth it.