gandrews@netcom.COM (Greg Andrews) (06/03/91)
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. The designers only had 1200 and 2400 bps modems to work with at the time (78 or 79, I believe), and not the same modems as many folks use today. As such, somebody with a different type of modem may not get the same results. They may need to adjust the protocol's operation to get optimal performance. >-Roger >{mtxinu,pacbell,amdahl,sun,hoptoad}!rtech!rog rog@ingres.com -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
mhw@fithp (Marc Weinstein) (06/07/91)
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
gandrews@netcom.COM (Greg Andrews) (06/08/91)
In article <1991Jun7.050757.18586@fithp> mhw@fithp (Marc Weinstein) writes: >From article <1991Jun3.024220.19047@netcom.COM>, by gandrews@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@netcom.COM | `------------------------------------------------------------------------'
bruce@balilly (Bruce Lilly) (06/08/91)
In article <1991Jun7.050757.18586@fithp> mhw@fithp (Marc Weinstein) writes: >From article <1991Jun3.024220.19047@netcom.COM>, by gandrews@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? 3 bits are allocated to describe the number of windows; 7 is the absolute maximum. The packet size can be up to 4096 bytes (in powers of 2), but it's not easy to change by patching the uucico binary (reason: the code uses an immediate load instruction (2 bytes) which cannot load a larger number than 64 without problems due to sign extension). There is a published description of the uucp g protocol; consult it for more details (it has been posted to comp.mail.uucp many times, and should be available at several archive sites). -- Bruce Lilly bruce%balilly@sonyd1.Broadcast.Sony.COM
clewis@ferret.ocunix.on.ca (Chris Lewis) (06/08/91)
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!
burris@highspl (David Burris) (06/09/91)
From article <1991Jun8.020327.10713@netcom.COM>, by gandrews@netcom.COM (Greg Andrews): > In article <1991Jun7.050757.18586@fithp> mhw@fithp (Marc Weinstein) writes: >>From article <1991Jun3.024220.19047@netcom.COM>, by gandrews@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@highspl ..!linac!highspl!burris ================================================================
gandrews@netcom.COM (Greg Andrews) (06/09/91)
In article <1991Jun8.205320.2659@highspl> burris@highspl (David Burris) writes: >> >> Well, uucp "g" can't go above a window size of 7, as I mentioned in my >> last article. > >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. > Oh? A simple patch will allow packet ID numbers greater than 7? Take a look at the code that extracts the packet number from the received data bytes. Surprise! As has meen mentioned in a previous article (not mine), the uucp "g" protocol uses a SINGLE BYTE to send the packet information. There are five other bytes in the packet header, but they don't carry the info for the window. For data packets that byte contains three pieces of information: o The packet type (most significant two bits) o The packet identification number (next most significant three bits) o The ID number of the last acked packet (least significant three bits) So, for data packets, there are only three bits in the ID field. That means packets can only have eight ID numbers, zero through seven. A windowed protocol must NEVER have a window size equal to or greater than the packet numbering scheme. The window size must ALWAYS be at least one less than the packet numbering scheme. Since uucp "g" uses eight packet numbers (because the packet counter is three-bits wide), the window size cannot be larger than 7. You can patch your tests to check if the packet number is equal to 8, or 9 or 23 if you like, but all it will do is give you a BROKEN protocol. You can't use more than eight packet ID numbers, so you can't use a window larger than 7. Someone could certainly patch their system to insert an extra byte as the packet counter and use window sizes up to 255, but so what? It wouldn't be uucp "g" anymore. It would be a new protocol incompatible with all other uucp systems. >David Burris Aurora,Il. >burris@highspl ..!linac!highspl!burris -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
burris@highspl (David Burris) (06/09/91)
From article <1991Jun9.063022.229@netcom.COM>, by gandrews@netcom.COM (Greg Andrews): > In article <1991Jun8.205320.2659@highspl> burris@highspl (David Burris) writes: >>> >>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. >> > > Oh? A simple patch will allow packet ID numbers greater than 7? Take a > look at the code that extracts the packet number from the received data > bytes. Surprise! > > As has meen mentioned in a previous article (not mine), the uucp "g" > protocol uses a SINGLE BYTE to send the packet information. There are > five other bytes in the packet header, but they don't carry the info > for the window. For data packets that byte contains three pieces of > information: > > o The packet type (most significant two bits) > o The packet identification number (next most significant three bits) > o The ID number of the last acked packet (least significant three bits) Ok I hadn't gotten that far in my investigation yet. This would definately be a stopping point. If the protocol only allows three bits for the window number, the situation is hopeless for the 'g' protocol to use larger than 7. -- ================================================================ David Burris Aurora,Il. burris@highspl ..!linac!highspl!burris ================================================================