NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/archives/msdos/d/232

Text File | 1992-12-29 | 3.8 KB | 75 lines

Newsgroups: comp.archives.msdos.d
Path: sparky!uunet!pipex!ibmpcug!exnet!dcs.ed.ac.uk!sct
From: [e-mail] (Stephen Tweedie)
Subject: Re: *** WHAT'S THE BEST COMM PROTOCOL ***
In-Reply-To: [e-mail]'s message of 22 Dec 92 18:24:01 GMT
Message-ID: <[e-mail]>
Sender: [e-mail] (UseNet News Admin)
Organization: University of Edinburgh Dept. of Computer Science, Scotland
References: <[e-mail]> <olevnmr.725048641@sunfun>
Date: Tue, 29 Dec 1992 13:54:39 GMT
Lines: 62

In article <olevnmr.725048641@sunfun>, [e-mail] (olevnmr) writes:
> Just one thing to say here..
> DON'T USE KERMIT!!!!!!

> I recently was using kermit on my 1200 baud (gasp!) modem to load files
> from a unix box to my PC. The actual data transfer rate with kermit was
> about 30-35 cps. I found that it is about 2.5 times faster to uuencode
> files, transfer them as text, and then decode them. (4 times faster data
> transfer, but 1.37 times filesize increase by uuencoding) I would love to
> use zmodem, but unfortunately none of our machines at work support it,
> and I don't know offhand of a free unix package that does. Of course,
> what I really want is a 14.4 kbps modem... :-)

The trouble with Kermit is that it is compatible with just about
anything.  In particular, it will run on mainframes which basically
run in half-duplex mode (no simultaneous transmit/receive; once they
start inputing data, they are stuck there until they receive a CR).
The original kermit, then, sent a (short) line of data and then waited
for an acknowledgement before continuing, just to keep the other end
happy.

Of course, even a short packet can experience long delays getting from
point to point, so this idle time waiting for an acknowledgement hits
your performance.  Modern computer systems may not be subject to the
same restrictions as older mainframes, so there are two ways to
improve things...

Bigger packets:the end-to-end delay is less significant if you keep
the idle period constant but increase the busy period by sending more
data at once.  Of course, there is a potential problem - if you have a
noisy connection, then increasing the packet size also increases the
amount of work that has to be done when a packet fails to get through,
and also increases the likelyhood of a packet being corrupted.  So,
bigger packets can't always be used on a poor line.

Sliding windows: don't wait for an acknowledgement after the first
packet sent.  With a sliding window of two, you only wait after
sending the second packet (actually, you wait whenever there are two
unacknowledged packets outstanding).  The hope is that while you send
the second packet, the other end will receive and acknowledge the
first, so that once the second packet is out, the sender will have
received the first acknowledgement and so can proceed with sending the
next packet.  In other words, with a sufficiently large sliding
window, the sender never has to wait for an acknowledgement.

The default with most kermits is 90 byte packets and 1 sliding window;
increasing this to 1000-byte packets and 2 sliding windows (on a good
line) or 200-byte packets and 4 sliding windows (on a poorer line)
should allow you to saturate the modem line, for a massive boost to
performance.

There should NEVER be any harm in setting the parameters this high,
since the first thing two kermits do when talking to each other is
negotiate a mutually acceptable set of parameters, effectively using
the user-supplied values as an upper limit.  So, it should be safe to
set these higher parameters as a default for your kermit (in an
initialisation file, for example).

Hope this helps.
---
Stephen Tweedie <[e-mail]>   (Internet: <[e-mail]>)
Department of Computer Science, Edinburgh University, Scotland.