home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / nfs / 1931 < prev    next >
Encoding:
Text File  |  1992-07-22  |  3.5 KB  |  91 lines
  1. Newsgroups: comp.protocols.nfs
  2. Path: sparky!uunet!darwin.sura.net!mips!odin!sgihub!zola!twilight!speaker.wpd.sgi.com!coolidge
  3. From: coolidge@speaker.wpd.sgi.com (Don Coolidge)
  4. Subject: Re: NFS I/O Ops/seconds
  5. Message-ID: <nkkvj9s@twilight.wpd.sgi.com>
  6. Sender: news@twilight.wpd.sgi.com ( CNews Account at twilight.wpd.sgi.com )
  7. Organization: Silicon Graphics, Inc.
  8. References: <1992Jul22.061146.15641@u.washington.edu> <64081@hydra.gatech.EDU> <1992Jul22.185748.852@zia.aoc.nrao.edu>
  9. Distribution: usa
  10. Date: Wed, 22 Jul 92 22:29:57 GMT
  11. Lines: 78
  12.  
  13. Seems like some summary is in order.
  14.  
  15. 1) The standard NFS benchmark is nhfsstones. It will probably
  16. soon be replaced by LADDIS. Both are similar; in fact, the
  17. default mix of operations used by each is (at least was) the
  18. same. Reads/writes account for less than 35% of the mix.
  19.  
  20. 2) Sun (among others) has from time to time reported very
  21. high IOPS numbers by changing the mix to have even fewer reads
  22. and writes. This is not dishonest...it just means that the
  23. reporting requirements for the test should make some mention
  24. of the mix.
  25.  
  26. 3) Auspex has gotten well over 1000 IOPS with the standard
  27. nhfsstones operations mix, but that was indeed with
  28. 4 connected Ethernets, and using their own NFS load generator,
  29. not nhfsstones (they may well have also gotten wonderful numbers
  30. with nhfsstones, but I haven't seen any).
  31.  
  32. 4) LADDIS reccommends adding another Ethernet for every 200 IOPS.
  33.  
  34. 5) However, that's not really necessary...our own tests have shown
  35. that nhfsstones are at least as client-bound as they are server-bound
  36. and media-bound. We've seen well over 400 IOPS over a single Ethernet
  37. using nhfsstones with the default mix and with UDP checksumming
  38. enabled, between a Crimson server and a single Crimson client. We
  39. also see well over 500 IOPS with the same setup, but with two
  40. Crimson clients on the single Ethernet. Multiple Ethernets
  41. give an additional boost. So does use of FDDI instead of Ethernet
  42. (a big boost).
  43.  
  44. 6) To be able to make reasonable NFS performance comparisons, I
  45. think that at least the following need to be specified in the
  46. performance report (there may well be more; this is just off the
  47. top of my head):
  48.  
  49.     - Network topology (number of nets; medium being used; 
  50.                 number of clients per attached net)
  51.  
  52.     - Server:    Number and clock speed of CPUs
  53.             Medium Interface model and revision
  54.             O/S version
  55.             Number, kind, and size of disks attached
  56.             Is there an NFS accelerator, either external
  57.                or intrinsic?
  58.             Any other specialized hardware?
  59.             How much RAM?
  60.  
  61.     - Clients:    Number and clock speed of CPUs
  62.             Medium Interface Board model and revision
  63.             O/S version
  64.             Any acceleration onboard?
  65.             Any specialized hardware?
  66.             How much RAM?
  67.  
  68.     - General:    UDP checksumming enabled?
  69.             Mix of operations used
  70.             Benchmark - nhfsstones, LADDIS, other?
  71.  
  72. I've seen too many bogus comparisons made where The Competition's
  73. server was tested with underpowered, under-RAMed clients, or where
  74. different versions of the O/S were used on different clients, or
  75. where the mix was different, or the test, or...
  76.  
  77. LADDIS is supposed to allow us to compare apples and apples. But it
  78. seems to have gotten a tad too political to do so, as many of the
  79. items I mentioned above were suggested and rejected as part of
  80. the output report. Too bad.
  81.  
  82. Anyhow, if you want to be absolutely sure of your vendor 
  83. performance comparisons, run the tests yourself. There's
  84. just too much information that gets left out of reports -
  85. for all practical purposes, any such marketing performance
  86. reports are worthless.
  87.  
  88. Don Coolidge
  89. coolidge@speaker.wpd.sgi.com
  90.  
  91.