home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / nfs / 1950 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  2.9 KB
  1. Path: sparky!uunet!ogicse!hp-cv!hp-pcd!news1.boi.hp.com!cupnews0.cup.hp.com!tardy.cup.hp.com!raj
  2. From: raj@cup.hp.com (Rick Jones)
  3. Newsgroups: comp.protocols.nfs
  4. Subject: Re: NFS I/O Ops/seconds
  5. Message-ID: <BrwKwn.4nD@cup.hp.com>
  6. Date: 24 Jul 92 17:07:35 GMT
  7. Article-I.D.: cup.BrwKwn.4nD
  8. References: <nkkvj9s@twilight.wpd.sgi.com>
  9. Distribution: usa
  10. Organization: The Place Where Packets Go To Die
  11. Lines: 58
  12. X-Newsreader: Tin 1.1 PL4
  13.  
  14. coolidge@speaker.wpd.sgi.com (Don Coolidge) writes:
  15. : Seems like some summary is in order.
  16. : 
  17. : 2) Sun (among others) has from time to time reported very
  18. : high IOPS numbers by changing the mix to have even fewer reads
  19. : and writes. This is not dishonest...it just means that the
  20. : reporting requirements for the test should make some mention
  21. : of the mix.
  22. : 
  23.  
  24. My understanding is that the number of reads and writes remained the same,
  25. just that the sizes are changed. This is particularly true if you try to
  26. make comparisons between nhfsstone 1.22 (which I beleive was the last  of
  27. the nhfsstones that was supposed to be distributed) and nhfstone 2.0.X.
  28. (which really wasn't supposed to be distributed, but does get quoted by some 
  29. folks...)
  30.  
  31. : 4) LADDIS reccommends adding another Ethernet for every 200 IOPS.
  32. : 
  33. : 5) However, that's not really necessary...our own tests have shown
  34. : that nhfsstones are at least as client-bound as they are server-bound
  35. : and media-bound. We've seen well over 400 IOPS over a single Ethernet
  36. : using nhfsstones with the default mix and with UDP checksumming
  37. : enabled, between a Crimson server and a single Crimson client. We
  38. : also see well over 500 IOPS with the same setup, but with two
  39. : Crimson clients on the single Ethernet. Multiple Ethernets
  40. : give an additional boost. So does use of FDDI instead of Ethernet
  41. : (a big boost).
  42. : 
  43.  
  44. 400 and 500 IOPS on a single Ethernet? Neat. I suppose that was nhfsstone
  45. 2.0.X, or were there modifications to the benchmark (read/write) sizes?
  46. Or were all the volumes mounted "private"?  
  47.  
  48. : 6) To be able to make reasonable NFS performance comparisons, I
  49. : think that at least the following need to be specified in the
  50. : performance report (there may well be more; this is just off the
  51. : top of my head):
  52. : 
  53. :...
  54. : LADDIS is supposed to allow us to compare apples and apples. But it
  55. : seems to have gotten a tad too political to do so, as many of the
  56. : items I mentioned above were suggested and rejected as part of
  57. : the output report. Too bad.
  58. : 
  59.  
  60. Really? Which suggestsions were rejected? The list you gave sounded like
  61. the reporting requirements for LADDIS. Admittedly, I didn't make it to the
  62. last SPEC meeting, but all the previous meetings at which LADDIS was discussed,
  63. seemed to follow that thrust for reporting. Then again, having things happen
  64. at SPEC meetings is generally helped by attending. Some vendors don't get
  65. to the meetings. Too bad. Certainly happened the last time I didn't make it
  66. to a meeting.
  67.  
  68.  
  69. rick jones
  70. raj@cup.hp.com
  71. HP SPEC Rep for LADDIS
  72.