home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / protocol / nfs / 3047 < prev    next >
Encoding:
Text File  |  1993-01-05  |  2.4 KB  |  56 lines
  1. Newsgroups: comp.protocols.nfs
  2. Path: sparky!uunet!spool.mu.edu!sgiblab!sgigate!sgi!rhyolite!vjs
  3. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  4. Subject: Re: NFS packet size
  5. Message-ID: <ugkusv0@rhyolite.wpd.sgi.com>
  6. Organization: Silicon Graphics, Inc.  Mountain View, CA
  7. References: <u97b4fc@rhyolite.wpd.sgi.com> <C04t4o.K10@news.iastate.edu> <peterd.726170584@pjd.dev.cdx.mot.com>
  8. Date: Tue, 5 Jan 1993 19:27:53 GMT
  9. Lines: 45
  10.  
  11. In article <peterd.726170584@pjd.dev.cdx.mot.com>, peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
  12. > vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
  13. > 
  14. > >In article <1993Jan1.115015.17311@prl.dec.com>, boyd@prl.dec.com (Boyd Roberts) writes:
  15. > >> ...
  16. > >> > A dropped TCP fragment can result in a large amount of resending too.
  17. > >> 
  18. > >> True, but that all happens at the TCP/IP level which is far more
  19. > >> responsive than NFS's 1, 2, 4, 8 ... _second_ exponential backoff
  20. > >> when a datagram gets lost.
  21. > 
  22. > >In other implementations of NFS, the NFS timeout starts at 0.7 seconds
  23. > >not 1.0, and can be reduced to 0.1 seconds.  Please compare 0.1 seconds
  24. > >with the standard TCP timeouts.
  25. > 
  26. > It still doesn't compare very well, at least on paper. With one second
  27. > timeouts and 8K blocks, exponential retransmission ala NFS falls off
  28. > to 50% throughput at an Ethernet packet loss rate of 0.001, and to 25%
  29. > throughput at a loss rate of 0.004. With a 100 mS starting timeout,
  30. > throughput falls to 50% at a loss rate of 0.01, and 25% at 0.025 or
  31. > so. (all figures from eyeballing gnuplot graphs...)
  32.  
  33. Yes, 1.0 second NFS timeouts are painful.  Even at 0.7 sec, a 1% packet
  34. loss produces a 90% NFS throughput drop, as I have observed from 
  35. involuntary experiments.
  36.  
  37. But we're not talking about 1.0 or even 0.7 sec NFS timeouts, but about
  38. 0.1 sec. NFS timeouts.  I don't know how a 0.1 sec NFS retransmission
  39. timeout would work.  It might be fine with few enough unneeded
  40. retransmissions, since any reasonable NFS server does far more than 10
  41. reads or writes per second.
  42.  
  43.  
  44. > With TCP on a local net, however, the retransmission timer should
  45. > adapt to somewhere in the range of say 3 to 6 packet times (correct me
  46. > if I'm wrong...), and so in the worst case (loss rate 0.025, timer = 6
  47. > packet times) the throughput would be about 87%.
  48. > ...
  49.  
  50. In unmodified 4.3BSD style network code, the "fast" timer runs at 5 HZ,
  51. which means the smallest TCP timer and quickest retransmission you can
  52. have is 0.2 seconds.
  53.  
  54.  
  55. Vernon Schryver,  vjs@sgi.com
  56.