Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!coherent!dplatt From: dplatt@coherent.com (Dave Platt) Newsgroups: comp.sys.mac Subject: Re: MacKermit 0.9(40) problem? Message-ID: <10735@coherent.com> Date: 28 Sep 88 17:15:30 GMT References: <13825@cs.tcd.ie> Reply-To: dplatt@coherent.com (Dave Platt) Organization: Coherent Thought Inc., Palo Alto CA Lines: 88 In article <13825@cs.tcd.ie> fmodwyer@cs.tcd.ie (Frank O'Dwyer , ext. 1695) writes: > > I am using Mac Kermit 0.9 (40) to talk to a VAX and I find that > the effective speed of file transfer is far too slow. > > For example, on a 9600 baud line, downloading a file to the VAX > works at about 1700 effective baud, whereas uploading works at > approx. 4000 baud. This problem doesn't occur when using Kermit > between a PC and the same VAX, so I assume the problem lies with > Mac Kermit, not the VAX. Anybody got any ideas what I can do to > improve things? You don't mention whether you're running under MultiFinder or not; that may make a difference. MacKermit 0.9(40) is MultiFinder-friendly, and takes pains to call GetNextEvent() frequently while receiving packets... it does so several times during each packet, to ensure that other applications are able to get some time-slices during downloads. I suspect [haven't looked at the sources] that MacKermit is reading packets by starting up an asynchronous read on the modem port, and then "going to sleep" for some time (via a WaitNextEvent() call, if this service is available). It would then check the received-character queue when awakened, pull out as much of the packet as had been received, and (if the packet is now complete) would send an acknowledgement and request the next packet. This method of programming has the advantage that it doesn't tie up the computer during downloads, but it could introduce a significant delay at the end of each packet. Consider that at 9600 baud (almost 1000 characters/second) a single 95-character Kermit packet will be received in about 1/10 second. If MacKermit awakens only 3 or 4 times/second to check the serial-port queue, then it could introduce a delay two or three times as long as the actual packet-transmission time. This could account for the low download bandwidth you're seeing. A PC-based version of Kermit, written to run in a single-task environment unconcerned with sharing the machine with other programs, could simply poll the serial port in a tight loop; it would be able to respond and acknowledge instantly when the end-of-packet signal came through. The bad news: there's probably no way to reconfigure MacKermit to respond in less time to the end-of-packet condition, unless you're willing to go into the code with TMON or MacNosy, figure out the polling strategy, and patch the code [or are willing to download the entire set of sources from Columbia and rewrite them]. You could try running MacKermit in a "Unifinder" (non-MultiFinder) environment using System 4.2, which does not support WaitNextEvent if MultiFinder isn't active; this might trick MacKermit into scanning the queue more frequently. The same trick won't work in System 6.0, which provides WaitNextEvent even if MultiFinder isn't being used. The good news: you can download the file in much less time, using MacKermit, if your Vax's version of Kermit is reasonably up-to-date. The Kermit protocol allows for "extended" packet size. The most recent set of C-Kermit protocol sources (which are used in MacKermit 0.9(40) and in the last year's worth of Unix Kermit releases) can support packets of up to about 1000 characters. These large packets are a _real_ win when downloading files over 9600-baud lines, because the two Kermits will need to turn the line around (receiver sending an "ack" packet) only about 1/10 as often as if the default, 95-byte packets are used. This will reduce the MacKermit acknowledge-delay to insignificance. I've downloaded files from a Vax running Ultrix, to a Mac running MacKermit 0.9(30-something)b4, at 9600 baud, using these large packets.. The effective transfer rate was close to 900 bytes/second... and the connection was via a TIP (TCP/IP port switch running TELNET) that introduced a significant delay to the "ack" packet. Downloads were at least 5 times faster than with the default 95-byte packets. To enable this mode, go into MacKermit's Settings menu, pick the Protocol command, and set the "Receive packet size" to a large number (I believe that values up to 1000 can be specified). If your Vax's Kermit is up-to-date (i.e. if it includes the C-Kermit protocol modules that grok large packets) it will honor the request for large packets, and will download the file in big chunks. If your Vax's Kermit doesn't honor the Mac's request, then it's rather out-of-date, and should probably be updated; you can probably acquire a more recent version from the Kermit archives at Columbia University (I believe they've been moved to the "cunixc.columbia.edu" machine, but I'm not certain of that). Hope this helps... -- Dave Platt VOICE: (415) 493-8805 USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303 UUCP: ...!{ames,sun,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@sun.com, ...@uunet.uu.net