Why 3 and 7? (was Re: patching uucico)

[Greg Andrews]

In article <1991Jun7.050757.18586 at fithp> mhw at fithp (Marc Weinstein) writes:
>From article <1991Jun3.024220.19047 at netcom.COM>, by gandrews at netcom.COM (Greg Andrews):
>> 
>> 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?
>

Now we're getting over my head.  I know modems pretty well, but I'm still
a novice at Unix internals.  The impression I have is that the default
window size of 3 and packet length of 64 bytes ensured that the computer
never had to handle more than 210 characters in one burst, and the normal
allocations of clists (buffers) for RS232 ports would handle 210 bytes very
comfortably.  A sysadmin could enlarge the clist allocations, but that
would increase everybody's clists - not just the modem's.  Bigger clists
for RS232 ports that didn't need them meant valuable memory would be wasted.

>
>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.
>

Half a million microseconds to checksum 64 bytes and do a compare?
I think your computer is an order of magnitude faster than you give it
credit for.  Maybe two!  Even under a heavy load, I wouldn't expect it
to take that long.

>
>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.
>

Well, uucp "g" can't go above a window size of 7, as I mentioned in my
last article.  If you need to increase the balance between sender and
receiver to give the acks more time to come back, then you might want
to try increasing the packet length.  Boosting it up to 256 bytes and
dropping the window back down to 3 will still give you twice as much
time as when you had a window of 7 with 64 byte packets.


>Marc Weinstein
>{simon,royko,tellab5}!linac!fithp!mhw		Elmhurst, IL

-- 
 .------------------------------------------------------------------------.
 |  Greg Andrews   |       UUCP: {apple,amdahl,claris}!netcom!gandrews    |
 |                 |   Internet: gandrews at netcom.COM                      |
 `------------------------------------------------------------------------'