home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / sgi / admin / 281 < prev    next >
Encoding:
Text File  |  1993-01-23  |  4.3 KB  |  86 lines
  1. Newsgroups: comp.sys.sgi.admin
  2. Path: sparky!uunet!pipex!pavo.csi.cam.ac.uk!camcus!jp107
  3. From: jp107@cus.cam.ac.uk (Jon Peatfield)
  4. Subject: Re: Return of the Poor NFS performance
  5. In-Reply-To: miguel@boytoy.csd.sgi.com's message of 22 Jan 93 22:14:47 GMT
  6. Message-ID: <JP107.93Jan23015219@apus.cus.cam.ac.uk>
  7. Sender: news@infodev.cam.ac.uk (USENET news)
  8. Nntp-Posting-Host: apus.cus.cam.ac.uk
  9. Organization: U of Cambridge, England
  10. References: <JP107.93Jan22121147@grus.cus.cam.ac.uk>
  11.     <1993Jan22.221447.10697@odin.corp.sgi.com>
  12. Distribution: comp
  13. Date: Sat, 23 Jan 1993 01:52:22 GMT
  14. Lines: 70
  15.  
  16.  
  17. In article <1993Jan22.221447.10697@odin.corp.sgi.com>  miguel@boytoy.csd.sgi.com  (Michael/Miguel Sanchez) writes:
  18. > In article <JP107.93Jan22121147@grus.cus.cam.ac.uk>, jp107@cus.cam.ac.uk (Jon Peatfield) writes:
  19. > |> Ok, I've had a few nice chats with some of the readers of this group
  20. > |> and with our local SGI support line, who are currently off chasing the
  21. > |> fact that this has been reported to them before but they couldn't find
  22. > |> what had happened last time (what kind of help-desk software does the
  23. > |> support line use?)
  24. > |> 
  25. > |> Anyway it turns out that my SGI Indigos can only push files over NFS
  26. > |> at about 10 to 30 Kbytes/sec (after the patch mentioned below) while
  27. > |> all the rest of our machines (Sun/HP/Mac), can manage over
  28. > |> 110Kbytes/sec (I have a large number of figures if you want them.)  I
  29. > |> got a set of patches from SGI for general network performance (a new
  30. > |> ethernet device driver), which improved performance a good deal, but
  31. > |> still didn't put it in the acceptable range.  After hitting my head
  32. > |> for a while and replacing transceivers and moving machines etc, I
  33. > |> watched the network with etherfind (great tool -- why don't SGI
  34. > |> provide it?) and spotted that the SGIs are waiting after each NFS
  35. > |> write for an acknowledgement from the server.  Our servers don't
  36. > |> acknowledge 'til the block is on physical disk (like normal machines),
  37. > |> so there is a huge wait.  This is as if the biod daemons are not
  38. > |> working (but we have four (4) running.)  On all the other machines in
  39. > |> the dept, if I have N biods then I don't see blocking 'til N+1
  40. > |> requests are outstanding.  The delays get worse when one is over a
  41. > |> high latency netwrok while other machines just cope.  What is worse is
  42. > |> that if the Acknowledgement reply is lost (as sometimes happens on
  43. > |> ethernets (it is UDP after all)), the SGI waits for 4.5 SECONDS before
  44. > |> retrying the send.  A few of those and the time really adds up.
  45. > 
  46. > it almost sounds like you are hard mounting the nfs mount points...are you
  47. > doing that?
  48. > 
  49.  
  50. Umm, have you tried reading the manual?  (I don't want to be rude, but...)
  51.  
  52. It isn't clear what part you are replying to here, sorry about the
  53. bandwidth guys!
  54.  
  55. The only difference that hard/soft mounting makes is that with soft
  56. mounting after RETRANS retransmissions a soft mount will give up and
  57. return an error, while a hard mount will repeat the call forever.
  58.  
  59. To quote the SGI manual (as that would disagree with any other NFS manual):
  60.  
  61.     Once the filesystem is mounted, each NFS request waits timeo=n tenths of
  62.     a second for a response.  If no response arrives, the time-out is multi-
  63.     plied by 2 and the request is retransmitted.  When retrans=n retransmis-
  64.     sions have been sent with no reply a soft mounted filesystem returns an
  65.     error on the request and a hard mounted filesystem retries the request.
  66.     Filesystems that are mounted rw (read-write) should use the hard option.
  67.     The number of bytes in a read or write request can be set with the rsize
  68.     and wsize options.
  69.  
  70. The default timeno is 7, so it should only wait 0.7 sec before
  71. retrying!  I will admit that the 4.5 sec delays were not measured by
  72. myself but by another person a mile down the road who is also unhappy
  73. about the NFS performance so I can't say with hand on heat tht I know
  74. what his setup was... perhaps I should start a club ;-)
  75.  
  76. In fact all the mounts I've been doing are soft mounts if that did
  77. make any difference!
  78.  
  79. -- Jon
  80. --
  81. Jon Peatfield, Computer Officer, the DAMTP, University of Cambridge
  82. Telephone: (+44 223) 3-37852     Mail: J.S.Peatfield@amtp.cam.ac.uk
  83.  
  84. To be consistent with DNS domain ordering, shouldn't news groups have
  85. names like "admin.sun.sys.comp" not "comp.sys.sun.admin" ?  EMWTK
  86.