Article 54211 of comp.sys.cbm: Xref: undergrad.math.uwaterloo.ca comp.sys.cbm:54211 Newsgroups: comp.sys.cbm Path: undergrad.math.uwaterloo.ca!csbruce From: csbruce@ccnga.uwaterloo.ca (Craig Bruce) Subject: Re: Zmodem send Sender: news@undergrad.math.uwaterloo.ca (news spool owner) Message-ID: Date: Mon, 20 May 1996 19:36:23 GMT References: <4nfm6f$p5t@ocean.CAM.ORG> <4nnqh6$ph0@news.inforamp.net> Nntp-Posting-Host: ccnga.uwaterloo.ca Organization: University of Waterloo, Canada (eh!) Geoffrey Welsh wrote: >Thanks for filling us in on FX. >In article <4nfm6f$p5t@ocean.CAM.ORG>, ismael@CAM.ORG (Ismael Cordeiro) wrote: >>About "Good luck even trying to HALF it!" I did some comparative tests with >>Desterm's Ymodem (1024-byte blocks) and FX (14790-byte blocks). I downloaded >>a 202,574-byte zip archive (deflated) 5 times with each protocol from the >>same system. With both I downloaded to the ramdisk. The average for FX was >>1570 cps and for Desterm's Ymodem was 1113 cps. That's more than half of FX' >>speed, actually 70%. Not bad for a protocol that uses 1024-byte blocks >>instead of 14790-byte blocks. ;-) > > ... and can handle files as large as you have space to store, no matter how >many blocks that may be! Now that's not entirely fair. I don't know what is going wrong, but FX works on most systems but not on others, where it runs into CRC errors for some packets for some reason. I think that it is either a problem with the link not being truly 8-bit clean, the Unix file channel not being truly clean, or a bug in the client program. It may be intermediate hardware on the host site too (terminal server). On most systems, including my Unix systems (SunOS-4 and AIX 4.1), FX works flawlessly. Also, I don't consider it unfair to have a better design. All's fair in love and computer systems. Large packet sizes are no real problem with high-speed modems, since they have their own stream-oriented error- correcting protocols anyway, and the only potential for problems are software misconfigurations and bugs. Also, the ARQ approach used by high-speed modems means increased latency for line turnarounds, which means that using the largest packet sizes possible is a very good idea. I plan to have about a 50K packet size for the C128 eventually. ACE also has the advantage that it supports the 115.2kbps-hacked SwiftLink. I assume that ACE also has more internal efficiency, to handle higher data rates (I'm thinking that the above figures are for a 14.4kbps modem, which ACE ends up just waiting for; how do you pull more than 1570 cps out of a 1440 cps link? :-) ). For my own testing, I downloaded a ~190K text file (the contents of C= Hacking Magazine Issue #12) and a 183K ZIP file with my hacked SwiftLink with the following results: Text file, 1024-byte packets: 2613 cps Text file, 14790-byte packets: 4480 cps ZIP file, 1024-byte packets: 1688 cps ZIP file, 14790-byte packets: 2341 cps <=== 2.10x But, what I was referring to before was using FX with real disk drives (since, as far as I know, DesTerm 2.00 (what I used, since I didn't like 2.01) didn't have an internal ramdisk to compare to). My test drive was the CMD hard drive, and with an unhacked 38.4-kbps SwiftLink and a 14.4kbps modem: Using FX to/from my CMD Hard Drive: Download 156,260 bytes of ~text: time= 83.4 sec, rate=1874 cps. Download 151,267 bytes of tabular text: time= 75.4 sec, rate=2006 cps. Download 141,299 bytes of JPEG image: time=118.2 sec, rate=1195 cps. Upload 156,260 bytes of ~text: time= 77.9 sec, rate=2006 cps. Upload 151,267 bytes of tabular text: time= 66.2 sec, rate=2285 cps. Upload 141,299 bytes of JPEG image: time=114.2 sec, rate=1237 cps. Using DesTerm-128 v2.00 to/from my CMD Hard Drive, Y-Modem: Download 156,260 bytes of ~text: time=189.5 sec, rate= 824 cps. Download 151,267 bytes of tabular text: time=180.4 sec, rate= 839 cps. Download 141,299 bytes of JPEG image: time=199.9 sec, rate= 707 cps. Upload 156,260 bytes of ~text: time=255.1 sec, rate= 611 cps. Upload 151,267 bytes of tabular text: time=238.6 sec, rate= 634 cps. Upload 141,299 bytes of JPEG image: time=233.0 sec, rate= 606 cps. I think that I'll continue to use FX. Keep on Hackin'! -Craig Bruce csbruce@ccnga.uwaterloo.ca "Never underestimate the power of a simple tool." C=256,64K-VDC,REU,RL16,HD200,FD4000,SL,USR28.8,C=128,1581,1571,C=64C,1541,VIC20