home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / sgi / 16013 < prev    next >
Encoding:
Text File  |  1992-11-05  |  2.2 KB  |  55 lines

  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!sgi!rhyolite!vjs
  3. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  4. Subject: Re: nullrecv question
  5. Message-ID: <s055l7g@rhyolite.wpd.sgi.com>
  6. Organization: Silicon Graphics, Inc.  Mountain View, CA
  7. References: <1992Nov4.101627.10106@crow.omni.co.jp>
  8. Date: Thu, 5 Nov 1992 18:07:37 GMT
  9. Lines: 44
  10.  
  11. In article <1992Nov4.101627.10106@crow.omni.co.jp>, trich@crow.omni.co.jp (Timothy Richards) writes:
  12. > ...
  13. > I noticed these things too and raised the issue with support, I also
  14. > noticed that these situations only occur on multi-cpu machines.
  15. > Anyway here are the responses I got from NSG/SGI support
  16. > ( which seemed quite unsatisfactory and I guess I just decided to drop
  17. > the matter.)
  18. > > There is a slight difference between irix3.3+ and irix4.0+.
  19. > > Under 3.3 all network processes ran on the same processor.
  20. > > Under 4.0+ the networking processes can run on different processors
  21. > > to distribute the load (this improves performance).
  22. > > 
  23. > > That was the only change I found.
  24. > > 
  25. > > To lock all network processes to one processor on a 4.0+ multi processor
  26. > > machine you would have to change /etc/init.d/network, like this: 
  27. > > 
  28. > > #        if test -x /usr/etc/rtnetd; then
  29. > > #            # Always start on multiprocessors for better throughput
  30. > > #            if $IS_ON rtnetd || test `mpadmin -u | wc -l` -gt 1; then
  31. > > #                /usr/etc/rtnetd `cat $CONFIG/rtnetd.options 2> /dev/null`
  32. > > #                                                        $ECHO " rtnetd\c"
  33. > > #            fi
  34. > > #        fi
  35. > > 
  36. > > You might try that as an experiment; but, it would reduce network
  37. > > performance.
  38. > Well this isn't what the man page for rtnetd says at all !!!
  39. > The man page says that rtnetd halts network packet processing whenever
  40. > the load gets too high.  So this seems to be very missleading advice.
  41.  
  42.  
  43. Your rtnetd man page must have come from some other computer vendor.
  44. Ours says:
  45.  
  46.     Rtnetd is a kernel daemon that allows higher-priority real-time processes
  47.     to preempt processing of incoming network packets.  Preemption gives
  48.     better response for real-time processes.
  49.  
  50.  
  51.  
  52. Vernon Schryver,  vjs@sgi.com
  53.