Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bbn!csd4.milw.wisc.edu!uxc!tank!eecae!shadooby!sharkey!clmqt!scott From: scott@clmqt.UUCP (Scott Reynolds) Newsgroups: news.admin Subject: Re: List of sites with broken Followup (No References) Software Message-ID: <244@clmqt.UUCP> Date: 20 May 89 06:55:02 GMT References: <99.2474C600@jsheese.FIDONET.ORG> Organization: Enterprise BBS, Marquette, MI Lines: 63 From article <99.2474C600@jsheese.FIDONET.ORG>, by jeffery@jsheese.FIDONET.ORG (Jeff Sheese): >Maybe I'm mis-judging it from the implementation that I'm using, but at 1200 >baud I average 92 cps and at 2400 baud I average 190cps. This is whether the >connections are local or via PC Pursuit. Of course I can't expect much more >using a packet size of 64 bytes. > >It appears that with G, each packet requires an ACK regardless of the window >size. With zmodem the transmission of data from origin to recipient is >continuous, where the recipient tells the sender if any problems occur in My xferstats file shows some interesting figures. On a direct dial 2400 baud connection, average transfer rate (for files of at least 5K or bigger) is 193 cps. On a clean line, G will actually do up to about 222 cps, believe it or not! Compare this to my best ZModem times of 231 cps and not one character higher, ever. I average 226 cps on ZModem transfers. On a 1200 baud connection through a packet switched network to an Internet gateway to the host, I get 93 cps on average. Best conditions yield up to about 109 cps, but that happens extremely rarely. >transmission. Packet size starts at 1024 bytes at 1200 baud (2048 at 2400 >baud) and adjust themselves according to line conditions. It even has error >recovery on partial transfers. Not sure what version of ZModem you are using -- DSZ for MS-DOS? My implementation, the rz/sz programs, start at 512 and 1024 for 1200 and 2400 baud, respectively. However, as long as the transfer runs clean, the block size adjusts, and it's not hard to achieve a 4K block with a fair sized file. Block size adjusts down to 16 (!) bytes on my implementation in bad conditions. >Now I'm not saying one technology is better than another. I would. ZModem uses 32-bit CRC checking, has error recovery (as mentioned already), exceptionally quick error handling, and myriads of other little features that really make it a solid protocol. There are a few protocols that edge it out in speed, such as SEAlink, but they are in general far less reliable, at least in theory. G is indeed streaming (watch it go when you are connected through a packet network if you don't believe me) but the one thing that really slows it down is poor error recovery. If in mid transfer a block is short a few characters, the receiver will time out after a fairly long period of time. I say fairly long because I have watched the TD/RD indicators on the modem stay unlit for periods of 10-20 seconds; I would think that in a direct dial connection that a more reasonable timeout would be 3-5 seconds. Then again I'm not a protocol designer so I shouldn't second guess, should I? :-) >... Maybe that makes it an unfair comparison. It's a fair comparison -- rz/sz run on most USG/Sys V, BSD, XENIX, and other mostly compatible *NIX systems, as well as versions for VMS. If your site doesn't have the programs you hardly know what you're missing. There are even hints that you can tie rz into news in the documentation, but as of yet I haven't attempted it. I believe the package is archived, but if you're having trouble finding it and don't mind paying a little bit of long distance, the number you can find it at is +1 503 621 3746 2400 baud 8,1,n. -- Scott Reynolds scott@clmqt.UUCP ..rutgers!sharkey!clmqt!scott Enterprise Information System Marquette, MI