home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / sgi / admin / 277 < prev    next >
Encoding:
Text File  |  1993-01-23  |  2.6 KB  |  53 lines
  1. Newsgroups: comp.sys.sgi.admin
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!sgiblab!sgigate!odin!boytoy.csd.sgi.com!miguel
  3. From: miguel@boytoy.csd.sgi.com (Michael/Miguel Sanchez)
  4. Subject: Re: Return of the Poor NFS performance
  5. Message-ID: <1993Jan22.221447.10697@odin.corp.sgi.com>
  6. Sender: news@odin.corp.sgi.com (Net News)
  7. Nntp-Posting-Host: boytoy.csd.sgi.com
  8. Organization: Silicon Graphics, Inc.
  9. References:  <JP107.93Jan22121147@grus.cus.cam.ac.uk>
  10. Distribution: comp
  11. Date: Fri, 22 Jan 1993 22:14:47 GMT
  12. Lines: 39
  13.  
  14. In article <JP107.93Jan22121147@grus.cus.cam.ac.uk>, jp107@cus.cam.ac.uk (Jon Peatfield) writes:
  15. |> Ok, I've had a few nice chats with some of the readers of this group
  16. |> and with our local SGI support line, who are currently off chasing the
  17. |> fact that this has been reported to them before but they couldn't find
  18. |> what had happened last time (what kind of help-desk software does the
  19. |> support line use?)
  20. |> 
  21. |> Anyway it turns out that my SGI Indigos can only push files over NFS
  22. |> at about 10 to 30 Kbytes/sec (after the patch mentioned below) while
  23. |> all the rest of our machines (Sun/HP/Mac), can manage over
  24. |> 110Kbytes/sec (I have a large number of figures if you want them.)  I
  25. |> got a set of patches from SGI for general network performance (a new
  26. |> ethernet device driver), which improved performance a good deal, but
  27. |> still didn't put it in the acceptable range.  After hitting my head
  28. |> for a while and replacing transceivers and moving machines etc, I
  29. |> watched the network with etherfind (great tool -- why don't SGI
  30. |> provide it?) and spotted that the SGIs are waiting after each NFS
  31. |> write for an acknowledgement from the server.  Our servers don't
  32. |> acknowledge 'til the block is on physical disk (like normal machines),
  33. |> so there is a huge wait.  This is as if the biod daemons are not
  34. |> working (but we have four (4) running.)  On all the other machines in
  35. |> the dept, if I have N biods then I don't see blocking 'til N+1
  36. |> requests are outstanding.  The delays get worse when one is over a
  37. |> high latency netwrok while other machines just cope.  What is worse is
  38. |> that if the Acknowledgement reply is lost (as sometimes happens on
  39. |> ethernets (it is UDP after all)), the SGI waits for 4.5 SECONDS before
  40. |> retrying the send.  A few of those and the time really adds up.
  41.  
  42. it almost sounds like you are hard mounting the nfs mount points...are you
  43. doing that?
  44.  
  45.  
  46.  
  47.  
  48. -- 
  49. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  50. Miguel (Michael) J. Sanchez
  51. miguel@csd.sgi.com            
  52. Member Technical Staff, Silicon Graphics, Inc.         
  53.