home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / dcom / modems / 13057 < prev    next >
Encoding:
Text File  |  1992-09-08  |  1.6 KB  |  41 lines
  1. Newsgroups: comp.dcom.modems
  2. Path: sparky!uunet!utcsri!geac!torsqnt!uunorth!anton
  3. From: anton@analsyn.gts.org (Anton J Aylward)
  4. Subject: Re: UUCP 'G' protocol packet size
  5. Message-ID: <1992Sep6.204014.8017@analsyn.gts.org>
  6. Organization: ASCI: UNIX Database and Communications
  7. X-Newsreader: Tin 1.1 PL4
  8. References: <1079@bazooka.amb.org>
  9. Date: Sun, 6 Sep 1992 20:40:14 GMT
  10. Lines: 29
  11.  
  12. ti@bazooka.amb.org (Ti Kan) writes:
  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. : ....
  20. : 
  21. : With the previous paragraph in mind, I looked into the version of
  22. : uucico that I'm using and found that the "packet size" is hardwired
  23. : to 64 bytes.  So the question is, is there any benefit in increasing
  24. : this to something like 4096 bytes?  Do I run the risk of making my
  25. : uucico incompatible with other systems?
  26.  
  27. Think about it for a moment.
  28. Assuming you don't have the WB bug...
  29. If the remote site doesn't like 7,4096 it will negotiate what it wants.
  30. The "paths" (or parameter in SVR4) just sets a starting point.
  31.  
  32. Benefit?  fewer system calls.  Better response because of less
  33. processing switching, less overhead (but not dramitcally so) in
  34. calculating csum, less moving of data.  Write out a simple simulation of
  35. the basic flow and you'll see what I mean.  The big saving is in fewer
  36. system calls.  Conventional wisdom:  system calls are more expensive
  37. than subroutine calls within a process.
  38.  
  39. --
  40. Anton J Aylward
  41.