home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / dcom / modems / 12990 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  2.0 KB
  1. Xref: sparky comp.dcom.modems:12990 comp.mail.uucp:1744
  2. Path: sparky!uunet!sun-barr!olivea!sgigate!sgiblab!bazooka!ti
  3. From: ti@bazooka.amb.org (Ti Kan)
  4. Newsgroups: comp.dcom.modems,comp.mail.uucp
  5. Subject: UUCP 'G' protocol packet size
  6. Message-ID: <1079@bazooka.amb.org>
  7. Date: 4 Sep 92 17:34:37 GMT
  8. Reply-To: ti@bazooka.amb.org (Ti Kan)
  9. Followup-To: comp.dcom.modems
  10. Organization: AMB Research Labs, Sunnyvale, CA.
  11. Lines: 33
  12.  
  13. I have been playing around with the UUCP 'G' protocol by increasing
  14. my uucico's supported window size from 3 to 7.  This yielded a nice
  15. ~20% boost in throughput when transferring compressed news batches.
  16. This appears to have no ill effects as far as compatibility with other
  17. systems go.
  18.  
  19. I have recently acquired the "Managing UUCP and Usenet" book from
  20. O'Reilly and in the G-Protocol Appendix, it gives a table of "K-Byte
  21. Value" in the packet header and the corresponding "Data Segment
  22. Length" in bytes (Pg. 313).  The table lists lengths as high as
  23. 4096 bytes.  I am assuming in this case "data segment == packet".
  24. Also, on Pg. 321 it says that although the G protocol allows for
  25. data packets with different K-values (physical lengths) to be sent
  26. in a session, in practice both ends always use the value negotiated
  27. at the start of the session.  On Pg. 314 it indicates that the
  28. maximum data segment size to use is negotiated in the INITB phase
  29. of the initial handshake.
  30.  
  31. With the previous paragraph in mind, I looked into the version of
  32. uucico that I'm using and found that the "packet size" is hardwired
  33. to 64 bytes.  So the question is, is there any benefit in increasing
  34. this to something like 4096 bytes?  Do I run the risk of making my
  35. uucico incompatible with other systems?
  36.  
  37. Any information would be greatly appreciated...
  38.  
  39. -Ti
  40. -- 
  41.     ///  Ti Kan                vorsprung durch technik
  42.    ///   AMB Research Laboratories, Sunnyvale, CA. USA
  43.   ///    ti@bazooka.amb.org
  44.  //////  ...!{decwrl,synopsys,tandem,tsoft,ultra}!sgiblab!bazooka!ti
  45. ///      ...!{uunet,sun,apple,sco}!altos!bazooka!ti
  46.