Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cis.ohio-state.edu!ucbvax!bloom-beacon!eru!hagbard!sunic!liuida!isy!ingemar From: ingemar@isy.liu.se (Ingemar Ragnemalm) Newsgroups: comp.sys.mac.comm Subject: Re: Downloading with Kermit (not slow with packet size 1000!) Message-ID: Date: 13 Jun 91 08:52:10 GMT References: <1991Jun7.112254.622@vax.oxford.ac.uk> <1991Jun12.205728.997@m.cs.uiuc.edu> Sender: news@isy.liu.se (Lord of the News) Organization: Dept of EE, University of Linkoping Lines: 38 gillies@m.cs.uiuc.edu (Don Gillies) writes: >kermit is perhaps the slowest download protocol in existence. It is >slow because the packet sizes are too small (128 bytes). If you use a >better protocol (xmodem, ymodem, or especially zmodem) you would be >much better off. In fact, binhex + zmodem would probably run faster >than macbinary + kermit. I tried Zmodem protocol (with Zterm), and for some reason it was slower than MacKermit. This was because of two reasons: - The Zmodem protocol didn't seem to work perfectly. It got some errors in transmission, which is strange since Kermit had no problems. - I used packet sizes over 1000 for MacKermit. This is much faster than the standard packet length. I know I posted about this just a few days ago, but it seems like it has to told pretty often. (Perhaps it should be put in the FAQ list.) Get a modern version of Kermit - on both sides. MacKermit should be version 0.98 (or newer, if there will ever be an upgrade). This gives you MacBinary file transfer (if you download from archives with binary storage, no more need for the extra step through the MacBinary program) and extended packet lengths. (And macros, and scrolling window.) I don't know the version number for the "other" side, but it should support extended packet length. You have to set the extended packet length yourself. Don't forget "save settings". -- Ingemar Ragnemalm Dept. of Electrical Engineering ...!uunet!mcvax!enea!rainier!ingemar .. University of Linkoping, Sweden ingemar@isy.liu.se