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

[David Burris]

>From article <1991Jun8.020327.10713 at netcom.COM>, by gandrews at netcom.COM (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):

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

A character buffer of size BUFSIZ is allocated on the stack and used
for the packet/window buffer.

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

The "clist buffers" (cblock structures) are allocated to the clists
DYNAMICALLY. The nttyhog parameter controls how many cblocks will be
allowed to accumulate in the input clist before the input cblocks
are silently returned to the freelist (dropped characters).

The nclist parameter controls the number of cblocks available for all
character devices on the system.

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

Potentially, yes. But this would mostly be true for FAST character
devices.

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

I think the time is probably spent more in waking processes waiting
for I/O, etc., not to mention the overhead of administering the
clists.

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

Yes, the max is seven, though it doesn't seem it needs to be. The
value used for the window size is a char. There are two spots where
the code checks for != 0 and two spots where the code sets the window
size back to 3 if it is greater than 7. If one wanted to find the
spots to patch the checks for greater that 7, it could be patched to
window_size = BUFSIZ/64. Check your /usr/include/stdio.h file for
BUFSIZ.

-- 
================================================================
David Burris					Aurora,Il.
burris at highspl		           ..!linac!highspl!burris
================================================================