Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!linac!highspl!fithp!mhw
From: mhw@fithp (Marc Weinstein)
Newsgroups: comp.sys.3b1
Subject: Re: Why 3 and 7? (was Re: patching uucico)
Message-ID: <1991Jun7.050757.18586@fithp>
Date: 7 Jun 91 05:07:57 GMT
References: <1991Jun3.024220.19047@netcom.COM>
Organization: Weinstein Consulting
Lines: 39

From article <1991Jun3.024220.19047@netcom.COM>, by gandrews@netcom.COM (Greg Andrews):
> In article <1991Jun2.224048.7111@ingres.Ingres.COM> rog@Ingres.COM (Roger Taranto) writes:
>>
>>How were the 3 and 7 chosen?  Is there any research on the optimal
>>number of un-ack'ed packets?  Why not raise it to 16 or 32 or ...?
> 
> Certain decisions in the initial design of the protocol determined the
> maximum window size and the default window size, along with the default
> packet length.
> 
> The protocol's design limits the maximum window size to 7.  The default size
> of 3 was probably just the figure that the designers found to be optimal
> for transfer:  Kept the data flowing in a steady stream, and didn't hog the
> system resources too much.

Is it that there isn't sufficient buffer space for more than 7 packets?
Are the buffers malloc'ed, or allocated from pre-malloc'ed space?
I've done some experimentation, and have observed that yes, 7 seems to
provide better throughput than 3, but it seems to be nowhere near enough.
With 9600 baud MNP (with compression), I observed around 500 Bps for
the 3-packet version, and around 830 Bps for the 7-packet version.

At 9600 baud (960 Bps), with 64 byte packets, it takes less than half
a second to hit the limit.  My guess is that even with the 7-packet
window, UUCP is spending almost as much time waiting for acknowledgement
packets as it is sending data.  I can easily envision the recognition
of the incoming packets, calculation of checksums, etc, to take more
than half a second, especially on a heavily loaded system.

If the window size could be increased to 15 or 31, that might be enough
to make the standard 'g' protocol effective at higher baud rates.  Or,
increasing the packet size should help (I think the 'G' protocol does
this?).  We've been forced to use the 'e' protocol to get any kind of
decent throughput.

-- 
Marc Weinstein
{simon,royko,tellab5}!linac!fithp!mhw		Elmhurst, IL
-or- {internet host}!linac.fnal.gov!fithp!mhw