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