Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!mauxci!eci386!ecicrl!clewis From: clewis@ferret.ocunix.on.ca (Chris Lewis) Newsgroups: comp.sys.3b1 Subject: Re: Why 3 and 7? (was Re: patching uucico) Message-ID: <2130@ecicrl.ocunix.on.ca> Date: 8 Jun 91 16:35:47 GMT References: <1991Jun3.024220.19047@netcom.COM> <1991Jun7.050757.18586@fithp> Organization: Elegant Communications Inc., Ottawa, Canada Lines: 40 In article <1991Jun7.050757.18586@fithp> mhw@fithp (Marc Weinstein) writes: >From article <1991Jun3.024220.19047@netcom.COM>, by gandrews@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@ferret.ocunix.on.ca UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!