home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / protocol / nfs / 2092 < prev    next >
Encoding:
Text File  |  1992-08-19  |  4.4 KB  |  91 lines
  1. Newsgroups: comp.protocols.nfs
  2. Path: sparky!uunet!snorkelwacker.mit.edu!stanford.edu!ames!sgi!rhyolite!vjs
  3. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  4. Subject: Re: Free NFS Response Time Measurement Software
  5. Message-ID: <op4fvdo@rhyolite.wpd.sgi.com>
  6. Summary: you never get more than what you pay for
  7. Organization: Silicon Graphics, Inc.  Mountain View, CA
  8. References: <1992Aug10.045921.13353@aim.com> <nxfyh!-@rpi.edu>
  9. Date: Wed, 19 Aug 1992 14:41:01 GMT
  10. Lines: 79
  11.  
  12. In article <nxfyh!-@rpi.edu>, fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald) writes:
  13. > NFS RTM Distribution writes:
  14. > >
  15. > >                    *************************************
  16. > >                    FREE NFS SERVER RESPONSE TIME UTILITY
  17. > >                    *************************************
  18. > 
  19. > ... cool program.  For anyone interested, here's an example output of
  20. > the free demo they sent me.  Good teaser for the sharpshooter.
  21. > ...
  22.  
  23. >                         NFS RESPONSE TIME REPORT
  24. >                 Failure Rate       NFS Response Time (ms)      NFS Load
  25. > Server            Over  20ms           Avg        Max         (ops/sec)
  26. > -----------------------------------------------------------------------
  27. > hammer                    0%           2.9        3.1               0.0
  28. > darwin                    0%           1.0        1.0               0.0
  29. > usenet                   20%          10.9       67.6               0.9
  30. > mml0                      0%           2.5        2.7               0.1
  31. > cds1                      9%           5.8       27.6               0.2
  32.  
  33.  
  34. I'd be very surprised if the AIM test is a fraction as interesting as
  35. LADDIS, the multi-vendor effort within SPEC to come up with an NFS
  36. benchmark.
  37.  
  38. Deciding what to measure is always hard, and particularly difficult
  39. with NFS.  Most people do not know and do not know they don't know
  40. which operations are common between an NFS client and its server.  The
  41. response time of the server depends radically on which operations you
  42. assume are common, and about their nature.  Trivially, what block size
  43. do you assume?  What about client or server caching?  Both of those
  44. have 10X effects on read and write speed.  What about evil async
  45. writes, which can have >2X effects?  I would not trust a benchmark that
  46. did not spend a lot of time convincing me it's assumptions about client
  47. working set are reasonable; you can expect "response times" to vary by
  48. 100X depending on the size of the client working set.
  49.  
  50. The hard problem with the operation mix is that reads and writes are
  51. generally not as common as one would thing.  The exact operation mix
  52. for LADDIS has been controversial.  They have switched to a synthetic
  53. load generator from using real NFS clients.  I guess it was too hard to
  54. define a standard client.  (It's well known that the speed of the
  55. clients is at least as important as the speed of the server.)
  56.  
  57. Another controversy within the group working on LADDIS has been what,
  58. if any, single "figure of merit" or number the LADDIS benchmark should
  59. produce.  I don't recall seeing mention of "response time" for a long
  60. time.
  61.  
  62. I'd be very surprised if the AIM test is very valuable.  I could be
  63. wrong, of course, especially since I have never seen the AIM NFS test.
  64.  
  65. I don't make this attack lightly, but the history of commerical
  66. benchmarks is not pretty.  If you think the system vendors are scum,
  67. then you should check the benchmark slime.  Would it be fair to say
  68. that SPEC was formed as response to Dhrystone and the so called
  69. commercial CPU benchmarks?
  70.  
  71. If I wanted an NFS test, and if Silicon Graphics were not already
  72. involved, I'd wait a few more weeks and then buy the tape of LADDIS
  73. from SPEC.  (I think the SPEC CPU benchmark tape costs $200).
  74.  
  75. If I wanted a reasonable benchmark from people who understand NFS that
  76. is free or next to free, I'd contact Legato for a copy of nfshstone (it
  77. has an extra "h" in there somewhere).  It was the starting point for
  78. LADDIS and is the benchmark that NFS server vendors are currently
  79. competing on.  If you call a vendor and ask for numbers, you'll
  80. probably be able to get nhfsstone numbers.
  81.  
  82. If I didn't want to spend any money, I would simply get a copy of the
  83. Sun NFS validation suite.  It generates several numbers, and was the
  84. de facto benchmark among NFS developers for years.  It's numbers are
  85. not very good, but at least you get the source and can see exactly what
  86. it thinks it is measuring.  Of course, you also get the source for
  87. LADDIS and nfsshtone.
  88.  
  89.  
  90. Vernon Schryver,  vjs@sgi.com
  91.