home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / nfs / 1952 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  4.2 KB
  1. Path: sparky!uunet!sun-barr!news2me.ebay.sun.com!exodus.Eng.Sun.COM!ennoyab.Eng.Sun.COM!beepy
  2. From: beepy@ennoyab.Eng.Sun.COM (Brian Pawlowski)
  3. Newsgroups: comp.protocols.nfs
  4. Subject: Re: NFS I/O Ops/seconds
  5. Date: 26 Jul 1992 08:45:47 GMT
  6. Organization: Sun Microsystems Inc., Mountain View, CA
  7. Lines: 72
  8. Distribution: usa
  9. Message-ID: <l74phrINNcus@exodus.Eng.Sun.COM>
  10. References: <1992Jul22.061146.15641@u.washington.edu> <64081@hydra.gatech.EDU> <nkkvj9s@twilight.wpd.sgi.com>
  11. NNTP-Posting-Host: ennoyab
  12. Summary: nfs nhfsstone laddis
  13.  
  14. [A public follow-up].
  15.  
  16. I agree with Rick Jones. My take on the various status I've seen from
  17. both Sun and other vendor reps is that most of what was mentioned for
  18. reporting rules in Coolidge's posting is not a problem.
  19.  
  20. Reporting rules are simple: You must report all configuration details
  21. which affect NFS server performance. SPEC is nailing down specifically
  22. for NFS what the reporting rules are, so there is not misunderstanding,
  23. along with guidelines--I believe--for vendors who may have non-standard
  24. configurations. The August SPEC meeting in Lisle will continue this
  25. work.
  26.  
  27. "Run rules" are more contentious. Reporting rules are where you get to
  28. say how you set up and ran the tests. Run rules, on the other hand, are
  29. the "rules" you must adhere to when running the tests. This has been
  30. the source for alternating lively and heated discussion. I have
  31. disagreements with counterparts. Variety is the spice of life.
  32.  
  33. Also, to my highly informed knowledge, Sun has never engaged in
  34. reporting numbers for nhfsstone and PRE-LADDIS where we have modified
  35. the mix. Some field people may have done this in an attempt to match a
  36. customer's measured mix (that's why the knobs were put in in the first
  37. place).
  38.  
  39. Different versions of nhfsstone under construction (*before* it was
  40. called PRE-LADDIS) where the benchmark load characteristics varied from
  41. release to release has confused some prior reporting. That's why the
  42. LADDIS guys and SPEC got a little rigid regarding reporting results
  43. from the beta evaluation version (i.e., you can't)--things were already
  44. confused enough.  The whole point behind this SPEC process of trying to
  45. hammer out an agreed to NFS (server) benchmark is to bring some sanity
  46. and conformity to the process. I believe SPEC is helping in this
  47. regard--getting players in the NFS server market to hash out their
  48. issues in a server benchmark to provide a tool for the industry.
  49.  
  50. You mentioned that SPEC or LADDIS process is political. LADDIS
  51. evaluation is being complicated by different participant vendor
  52. concerns. My hope is that with sufficient feedback from the beta
  53. evaluation, and SPEC's structure of "balance of powers", that LADDIS
  54. will not suffer (and actually improve) as part of process.  I firmly
  55. believe that the changes occurring since January when it was funneled
  56. into SPEC have been for the better. It's not perfect (what is).
  57.  
  58. I've given up looking for perfection.
  59.  
  60. Is SGI a SPEC member? (I do believe so) If so, I *strongly* encourage
  61. you to raise your objections to your SPEC rep! Now is the time.  If you
  62. want, I'll put forward any concerns you have. I'll simply add them to
  63. my voluminous list. Anyone should feel comfortable evaluating
  64. PRE-LADDIS and getting comments back to either Bruce Keith
  65. at DEC (SPEC PRE-LADDIS Project Leader) or any SPEC representative.
  66. [Do we need a repost of the PRE-LADDIS info?]
  67.  
  68. Most of my concerns--which are somewhat nebulous--center on "workload
  69. model".  Does PRE-LADDIS (or for that matter nhfsstone) define
  70. sufficiently an NFS workload to justify its use as a benchmark?  I tend
  71. to believe "yes". I and several other engineers (outside of Sun)
  72. recently decided that PRE-LADDIS is a very powerful tool to aid in NFS
  73. server analysis. Regardless of the SPEC outcome, or acceptance of
  74. PRE-LADDIS as the mother-of-all NFS server benchmarks, the work as it
  75. now stands (evolved from nhfsstone from Legato) provides a great tool
  76. to accomplish analysis of NFS servers. I use it regularly to subject
  77. servers to a reproducible load to analyze effectiveness of changes to
  78. software or hardware.  Way cool.
  79.  
  80. Rusty Sandberg did a great job on nhfsstone. Mark Wittle (DG),
  81. Ken Teelucksingh (DEC) and John Corbin (Sun) did major efforts
  82. to get PRE-LADDIS (highly evolved from nhfsstone) to where
  83. it is today. Thanks.
  84.  
  85. Brian Pawlowski
  86.