home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / sgi / 16008 < prev    next >
Encoding:
Text File  |  1992-11-05  |  4.0 KB  |  97 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!spool.mu.edu!decwrl!sun-barr!sh.wide!wnoc-tyo-news!ccut!crow!trich
  3. From: trich@crow.omni.co.jp (Timothy Richards)
  4. Subject: Re: nullrecv question
  5. Message-ID: <1992Nov4.101627.10106@crow.omni.co.jp>
  6. Sender: trich@crow.omni.co.jp
  7. Reply-To: trich@crow.omni.co.jp
  8. Organization: Omnibus Japan, Inc.
  9. Date: Wed, 4 Nov 92 10:16:27 GMT
  10. Lines: 85
  11.  
  12. "Douglas E. James" <rz81134%executioner.d50.lilly.com@BRL.MIL> writes:
  13.  
  14. >     We are currently implementing a SGI PowerFile 100 fileserver.  I was
  15. > looking through the NFS manuals and ran across the nfsstat command.  The output
  16. > follows: (the machine is a 340S with 64MB memory running IRIX 4.0.4 using its
  17. > FDDI interface as the primary interface)
  18. > 
  19. > Server rpc:
  20. > calls      badcalls   nullrecv   badlen     xdrcall
  21. > 2244071    0          1377407    0          0
  22. > 
  23. >     Should I be concerned at the nullrecv number..? It appears to be a 
  24. > bit high.  I checked other machines that were exporting NFS directories, and
  25. > their counts were much lower for this nullrecv value.  
  26. > 
  27. >     I also noticed the nfsd were accumulating some time ......
  28.  
  29. I noticed these things too and raised the issue with support, I also
  30. noticed that these situations only occur on multi-cpu machines.
  31. Anyway here are the responses I got from NSG/SGI support
  32. ( which seemed quite unsatisfactory and I guess I just decided to drop
  33. the matter.)
  34.  
  35. > There is a slight difference between irix3.3+ and irix4.0+.
  36. > Under 3.3 all network processes ran on the same processor.
  37. > Under 4.0+ the networking processes can run on different processors
  38. > to distribute the load (this improves performance).
  39. > 
  40. > That was the only change I found.
  41. > 
  42. > To lock all network processes to one processor on a 4.0+ multi processor
  43. > machine you would have to change /etc/init.d/network, like this: 
  44. > 
  45. > #        if test -x /usr/etc/rtnetd; then
  46. > #            # Always start on multiprocessors for better throughput
  47. > #            if $IS_ON rtnetd || test `mpadmin -u | wc -l` -gt 1; then
  48. > #                /usr/etc/rtnetd `cat $CONFIG/rtnetd.options 2> /dev/null`
  49. > #                                                        $ECHO " rtnetd\c"
  50. > #            fi
  51. > #        fi
  52. > 
  53. > You might try that as an experiment; but, it would reduce network
  54. > performance.
  55.  
  56. Well this isn't what the man page for rtnetd says at all !!!
  57. The man page says that rtnetd halts network packet processing whenever
  58. the load gets too high.  So this seems to be very missleading advice.
  59.  
  60.  
  61. Again also NSG/SGI support writes....
  62.  
  63. > On our main source tree system we get:
  64. > 
  65. > calls      badcalls   nullrecv   badlen     xdrcall
  66. > 32317149   0          16653080   0          0          
  67. > 
  68. > It is running 4 nfsd processes and has been up 10 days.
  69. > 
  70. > >From "Managing NFS and NIS" by O'Reilly (a great book that we use):
  71. > 
  72. >   The nullrecv field is incremented whenever an nfsd daemon is 
  73. >   scheduled to run but finds that there is no packet on the 
  74. >   NFS service socket queue.  If the server is running an
  75. >   excessive number of nfsd daemons, it is possible that there 
  76. >   will be more runnable daemons than requests to drain from 
  77. >   the NFS socket, so some daemons wake up but do not receive
  78. >   any data.
  79. > 
  80. >   nullrecv > 0.  NFS requests are not arriving fast enough to keep    
  81. >   all of the nfsd daemons busy.  Reduce the number of NFS server 
  82. >   daemons untill nullrecv is not incremented
  83. > 
  84. > So, I dont think there is any problem. He might want to run
  85. > fewer nfsd daemons.
  86.  
  87. As you can see the explanation from NSG/SGI seems highly contraditory.
  88. Its my opinion that the nullrecv output on multi-cpu machines is
  89. broken and meaningless.  As for the accumilating cpu time of the nfsd,
  90. I don't know, I guess you can just take there word for it that its not
  91. a problem.
  92. -- 
  93. -----------------------------------------------------------------------------
  94. Timothy Richards, Omnibus Japan.        work: +81 (3) 5706-8357
  95. [Uucp]      ccut.cc.u-tokyo.ac.jp!crow!trich    home: +81 (3) 3720-4088
  96. [Internet]  trich@omni.co.jp
  97.