ked@garnet.berkeley.edu (Earl H. Kinmonth) (06/02/89)
This afternoon I conducted a series of experiments comparing the speed of zmodem and kermit for file transfers over the link depicted below: ATT 6310 (SCO Xenix) ==> leased 9600 baud line ==> Develnet Switch ==> packet switching network ==> SUN (Unix) On the receiving (SUN) side I used time rz -e time kermit -p m -i -e 1000 -r Using a binary file of 100K and a text file of 50K, kermit consistently required (roughly) 50 percent more elapsed time and 50 percent more billed time on the receiving machine than did zmodem. Each file was run twice under each protocol with only trivial differences in times. It may not be obvious from the documentation, but zmodem may be run from within kermit. For example, on my Xenix installation, from within kermit ! sz < /dev/tty1a > /dev/tty1a [-options] files(s) activates zmodem to send file(s) to a previously initiated rz -e session. I generally use a pd version of CU in preference to kermit on the transmit side because the former requires much less memory. I hope this information is of interest to at least a few others. Earl H. Kinmonth History Department University of California, Davis Davis, California 95616 916-752-1636 (2300-0800 PDT for FAX) 916-752-0776 (secretary) ucbvax!ucdavis!ucdked!cck (email) cc-dnet.ucdavis.edu [128.120.2.251] (request ucdked, login as guest)
davidsen@sungod.crd.ge.com (William Davidsen) (06/03/89)
In article <25165@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: | It may not be obvious from the documentation, but zmodem may be run from | within kermit. For example, on my Xenix installation, from within kermit | | ! sz < /dev/tty1a > /dev/tty1a [-options] files(s) | | activates zmodem to send file(s) to a previously initiated rz -e session. | I generally use a pd version of CU in preference to kermit on the transmit | side because the former requires much less memory. I generated a shell to do that and some error checking as well. It accepts an argument which is the program to run, and has a few other features, as well. Mail if you want a copy. bill davidsen (davidsen@crdos1.crd.GE.COM) {uunet | philabs}!crdgw1!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
ctchou@KODAK.COM (JOE CHOU, CTCHOU@KODAK.COM, INTERNET) (06/08/91)
In one of the digest, <van-bc!oneb!ondeck!degear@ucbvax.berkeley.edu> claimed that zmodem was three time faster than kermit. That had been my experience too until recently I found out that changing the kermit's packet length from the default value (80) to 1000 increased the transfer rate by a factor of 5 or so. Since I cannot use zmodem on VAX, I cannot compare them. Anybody using zmodem on VAX? What program are you using? Does anybody use RZSZ on VAX and Zterm on Mac? Do you have problem with that combination? Chou
splee@pogo.gnu.ai.mit.edu (Seng-Poh Lee, Speedy) (06/08/91)
In article <9106080216.AA26357@Kodak.COM> ctchou@Kodak.COM writes: >In one of the digest, <van-bc!oneb!ondeck!degear@ucbvax.berkeley.edu> >claimed that zmodem was three time faster than kermit. That had been my >experience too until recently I found out that changing the kermit's packet >length from the default value (80) to 1000 increased the transfer rate by a >factor of 5 or so. Since I cannot use zmodem on VAX, I cannot compare them. > >Anybody using zmodem on VAX? What program are you using? Does anybody use >RZSZ on VAX and Zterm on Mac? Do you have problem with that combination? > I use zmodem on a VAX, Suns, HPs, without any trouble. Don't know about Zterm on a Mac. I use dsz.com on the PC side and the standard rz and sz on the Vax and workstation side. I use Procomm+ and take advantage of the remote command feature to kick off dsz.com. Thus, if I'm on the VAX via Procomm+, I only have to type something like zget <filename> or zsend <filemane> to kick off zmodem on both sides. zget and zsend are DCL procedures that send Procomm the remote command to start dsz.com and then start rz or sz on the local end. Works great! -- Seng-Poh Lee splee@gnu.ai.mit.edu
zjdg11@hou.amoco.com (Jim Graham) (06/09/91)
In article <9106080216.AA26357@Kodak.COM> ctchou@Kodak.COM writes: [....] > recently I found out that changing the kermit's packet > length from the default value (80) to 1000 increased the transfer rate by a > factor of 5 or so. true...assuming the line conditions are good. the reason you see an increased throughput is the simple fact that you are sending a lot less overhead per a given amount of real data. if, on the other hand, the line was really bad, suddenly you waste a lot of time every time you have to retransmit an errored packet. somewhere in between is a good compromise, which Zmodem tries to find. Let's say, for example, that you have a fixed amount of overhead, we'll pick 42 chars (42 comes to mind thanks to the tape of Hitchhiker's Guide to the Galaxy that I've listened to 1000 times) for things such as packet sequencing, CRC-16 or CRC-32 error control, etc., per packet, and the size of the data section of the packet is your variable. Assuming no errors on the phone line, the larger the packet size, the less overhead per byte of real data. If, however, every so often you take a hit on the phone line, you now have a very large packet to retransmit, which is also costly as far as time goes. As the line quality degrades, the overhead required for CRC, etc., becomes small compared to the overhead for each retransmitted packet. And, of course, the larger the packet size, the higher the probability of an error during that packet. if your packet size is high enough on a noisy line, there is the chance that NO packet may get through w/o errors. So, you reduce the packet size in hopes of just getting SOMETHING through..... On a very bad phone line, and I have definitely seen some of those, you will notice that Zmodem drops the packet size to adjust for the quality of the line --- looking for that compromise. It searches for the breakeven point, where the percent overhead due to smaller packet size is about the same as the percent overhead due to retransmissions. If the line cleans up, the packet size works its way back up too. > Since I cannot use zmodem on VAX, I cannot compare them. why can't you use zmodem on the VAX? I admit, I've never tried this, but I seem to recall that the rzsz src is already prepared with #defines to make VMS happy. if not, I'm sure someone will reply to you with the steps needed to make it work. --jim Standard disclaimer....These thoughts are mine, not my employer's, and I'm on my time...not my employer's. ------------------------------------------------------------------------------ Share and Enjoy! (Sirius Cybernetics Corporation, complaints division) 73, de n5ial Internet: zjdg11@hou.amoco.com or grahj@gagme.chi.il.us Amateur Radio: TCP/IP: jim@n5ial.ampr.org (44.72.47.193) Packet: BBS went QRT for good...still searching for new one. ------------------------------------------------------------------------------
rdthomps@vela.acs.oakland.edu (Robert D. Thompson) (06/11/91)
In article <1991Jun9.011029.9635@hou.amoco.com> zjdg11@hou.amoco.com (Jim Graham) writes: >In article <9106080216.AA26357@Kodak.COM> ctchou@Kodak.COM writes: >[....] >> recently I found out that changing the kermit's packet >> length from the default value (80) to 1000 increased the transfer rate by a >> factor of 5 or so. > >true...assuming the line conditions are good. the reason you see an increased >throughput is the simple fact that you are sending a lot less overhead per >a given amount of real data. if, on the other hand, the line was really bad, >suddenly you waste a lot of time every time you have to retransmit an errored >packet. somewhere in between is a good compromise, which Zmodem tries to >find. [ and the discussion goes on... ] > > --jim > >Standard disclaimer....These thoughts are mine, not my employer's, and I'm >on my time...not my employer's. > Thanks for the post Jim!!! Now, You would be doing me a very big favor if you could discuss these implications for high-speed transfers, say on 9600/V32.bis. You may remember a few days back the postings about YMODEM Batch. From what I gathered, YMODEM Batch (or is it G) provides a streaming protocol...which I guess is sending without waiting for an acknowledge. Please elaborate (your posting above was very informative, thanks!). Regards |(8> --- Robert rdthomps@vela.acs.oakland.edu
zjdg11@hou.amoco.com (Jim Graham) (06/13/91)
In article <6989@vela.acs.oakland.edu> rdthomps@vela.acs.oakland.edu (Robert D. Thompson) writes: >In article <1991Jun9.011029.9635@hou.amoco.com> zjdg11@hou.amoco.com (Jim Graham) writes: >> >>true...assuming the line conditions are good. the reason you see an >>increased >>throughput is the simple fact that you are sending a lot less overhead per >>a given amount of real data. > > [ and the discussion goes on... ] >> >Thanks for the post Jim!!! you're welcome.... :-) > > You would be doing me a very big favor if you could > discuss these implications for high-speed transfers, say > on 9600/V32.bis. not sure what you're looking for....so I'll guess. let me know if I missed the point somewhere. someone please correct me if I'm wrong, but if all we're talking about is increasing the speed of the line, and assuming that the file xfer protocols can keep up (which seems reasonable to me....), the only thing we're talking about is increasing the speed.... a protocol that is more efficient at 2400 will still be more efficient at 14,400. that's assuming that the line speed is the only change. now, if you add error control, like V.42, you can play some games with protocol spoofing (like the Telebit does), and increase throughput somewhat. Basically, the idea is this: if you are already doing CRC-16 or CRC-32 between the modems, why send yet another set of CRC overhead for end-to-end? With protocol spoofing, the modem on the DTE that's sending the file examines the packet and checks its CRC. If the packet is valid, the modem goes ahead and sends the ACK to the DTE. if not, it sends a NAK. It then (this is pure assumption on my part --- I have no docs to prove this) probably strips off the CRC overhead and sends more or less only the real data. After the packet has been received cleanly at the receiving end and passed the modem connection's error control, it is delivered to the receiving DTE, which ACKs or NAKs the packet (but this only really goes as far as the modem connected to it). I've used this a couple of times with the Telebit T-2500 at home, and it certainly does seem to improve things a good bit. I do not, however, have any stats at all, and I rarely use X/Ymodem protocols (Zmodem serves me quite well in most cases), so I can't really say with any certainty how much impact it really seems to have. Also, I would like to point out that much of what I'm just said is borrowed from a document distributed by Telebit called tech.doc. Their explanation is much better than mine.....but I don't have it on disk here at work --- all I have is a printout. It is available for anonymous ftp...but I forgot what machines have it. > You may remember a few days back the postings about > YMODEM Batch. sorry...I was out of town all last week, and missed a good portion of the postings here..... > From what I gathered, YMODEM Batch (or is it G) provides > a streaming protocol...which I guess is sending without waiting > for an acknowledge. nope...according to the Telebit document I referenced earlier, and assuming I'm reading it right, Xmodem, Ymodem, Ymodem-G, Kermit, and UUCP-G all require ACKs and NAKs as the xfer goes on. I thought I'd seen something in the Zmodem docs that said Zmodem also required ACKs (which didn't sound right, since I never see TxD light up except when there are errors), but I can't find it now. > Please elaborate (your posting above was very informative, > thanks!). hopefully this one was at least a bit of what you were after...... later.... --jim Standard disclaimer....These thoughts are mine, not my employer's. ------------------------------------------------------------------------------ Share and Enjoy! (Sirius Cybernetics Corporation, complaints division) 73, de n5ial Internet: zjdg11@hou.amoco.com or grahj@gagme.chi.il.us Amateur Radio: TCP/IP: jim@n5ial.ampr.org (44.72.47.193) Packet: BBS went QRT for good...still searching for new one. ------------------------------------------------------------------------------