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

[Chris Lewis]

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):

>> [Re UUCP protocol g]

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

No.  It's because there's only 3 bits in the packet header for the window
number.  You can see them increment as part of one of the octal numbers
emitted during debug output from UUCP.

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

The main reason for this is that MNP is not full-duplex, and it takes time
for the link to "turn around".  You see this even when terminal connected
via your modem.  On slower modems and trailblazer PEP the link is full-duplex,
so the ACKs can come thru simultaneous with transmissions of packets.
With MNP, the modems have to stop transmitting after transmitting the
windowsize # of packets, turn around, transmit the ACKS, and turn around again.
(roughly).

Somewhat similar to trying to use "g" protocol over a X.25 PAD link.

With a MNP modem it's better to use e or f protocol because they don't
need so damn many acks, but the problem then becomes that you have to
have working hardware flow control at both ends.  Or slow the link down.
-- 
Chris Lewis, Phone: (613) 832-0541, Domain: clewis at ferret.ocunix.on.ca
UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List:
ferret-request at eci386; Psroff (not Adobe Transcript) enquiries:
psroff-request at eci386 or Canada 416-832-0541.  Psroff 3.0 in c.s.u soon!