home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / protocol / nfs / 3048 < prev    next >
Encoding:
Text File  |  1993-01-06  |  2.5 KB  |  54 lines
  1. Newsgroups: comp.protocols.nfs
  2. Path: sparky!uunet!noc.near.net!vaxeline.ftp.com!cream.ftp.com!jbvb
  3. From: jbvb@vax.ftp.com  (James B. VanBokkelen)
  4. Subject: Re: NFS packet size
  5. Message-ID: <930105183618@cream.ftp.com>
  6. Nntp-Software: PC/TCP NNTP
  7. Keywords: TCP NFS
  8. Lines: 37        
  9. Sender: root@vaxeline.ftp.com (vaxeline.ftp.com root account)
  10. Nntp-Posting-Host: whipped-cream.ftp.com
  11. Reply-To: jbvb@ftp.com
  12. Organization: FTP Software, Inc., Wakefield, MA
  13. References: <peterd.726170584@pjd.dev.cdx.mot.com> <51022@shamash.cdc.com>
  14. Date: Tue, 05 Jan 1993 18:36:18
  15.  
  16. In article <51022@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
  17.  
  18.     I'm not sure about your version of TCP, but 1 sec tends to be a
  19.     nominal value for determining when to retransmit.  You must also
  20.     accommodate "delayed acks" (200 msecs comes to mind for this value)
  21.     when determining when to retransmit.
  22.  
  23. In a good TCP, 1 sec. might be the initial value before any packets
  24. are exchanged, but the only way it would persist after the connection
  25. open would be if packet loss was such that you didn't get *any* clean
  26. send/ack cycles (without retransmits).  A TCP might wait 200 ms.
  27. after receiving a single short segment, but it ought to issue the ack
  28. as soon as the RHS of the window should be moved (see RFC 813).  This
  29. means that it normally won't dally when bulk data is being moved, and
  30. even if the last packet is small enough that a dally occurs, the ack will
  31. not wait any longer than the time to complete & reply to the RPC.
  32.     
  33.     You will also discover that NFS has an interesting delay pattern when
  34.     using TCP because of "delayed acks" (i.e. the last packet
  35.     is not a full MSS).  Disabling Nagle's algorithm does eliminate this delay
  36.     (some implementations allow you to do this).
  37.  
  38. Many versions of 4bsd TCP don't really have a correct implementation of Nagle.
  39. Nagle says that if there is no unacknowleged data in the retransmit queue,
  40. send the segment regardless of size.  4bsd chose to wait rather than send a
  41. short segment when nothing else is outstanding.  This produces the behaviour
  42. you describe, and may well vanish if you "disable Nagle", but Nagle himself
  43. isn't to blame.
  44.     
  45.     Is there some major point that needs rehashing?
  46.     
  47. The fact that TCP largely de-couples the network RTT from the server's
  48. disk is not anything I'd heard before, but that doesn't guarantee it's
  49. new.
  50.  
  51. James B. VanBokkelen        2 High St., North Andover, MA  01845
  52. FTP Software Inc.        voice: (508) 685-4000  fax: (508) 794-4488
  53.  
  54.