home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / protocol / nfs / 2097 < prev    next >
Encoding:
Text File  |  1992-08-19  |  2.4 KB  |  56 lines
  1. Newsgroups: comp.protocols.nfs
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!decwrl!sgi!rhyolite!vjs
  3. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  4. Subject: Re: Free NFS Response Time Measurement Software
  5. Message-ID: <opjofug@rhyolite.wpd.sgi.com>
  6. Organization: Silicon Graphics, Inc.  Mountain View, CA
  7. References: <1992Aug10.045921.13353@aim.com> <nxfyh!-@rpi.edu> <4-gyl#c@rpi.edu>
  8. Date: Wed, 19 Aug 1992 23:22:06 GMT
  9. Lines: 45
  10.  
  11. In article <4-gyl#c@rpi.edu>, fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald) writes:
  12. > Vernon Schryver writes:
  13. > >In article <nxfyh!-@rpi.edu>, fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald) writes:
  14. > >> >                    FREE NFS SERVER RESPONSE TIME UTILITY
  15. > >> >                    *************************************
  16. > >> 
  17. > >> ... cool program.  For anyone interested, here's an example output of
  18. > >> the free demo they sent me.  Good teaser for the sharpshooter.
  19. > >> ...
  20. > ...
  21. > >I'd be very surprised if the AIM test is very valuable.  I could be
  22. > >wrong, of course, especially since I have never seen the AIM NFS test.
  23. > >
  24. > >I don't make this attack lightly, but the history of commerical
  25. > >benchmarks is not pretty.  If you think the system vendors are scum,
  26. > ...
  27. > 
  28. > Don't know much about NFS, or NFS performance monitoring and tuning
  29. > myself, but at least look over the brochure before dismissing it out of
  30. > hand.
  31.  
  32. What kind of brochure contains enough technical information to evaluate
  33. something as complicated as a benchmark?  Brochures are generally 2 or
  34. 4 pages loing and are no more than come-on's to get you to look at the
  35. product.  It's not as if half a dozen numbers or a list of 6 features
  36. is enough to let you decide if a benchmark or a network file system is
  37. wonderful or junk.
  38.  
  39.  
  40. > More to the point, that NFS performance tuning is such a lucrative
  41. > business is a telling commentary on the reliability of NFS.
  42.  
  43. If that were rephrased that, I might agree.
  44.  
  45. "Reliability" is entirely separate from "speed".  Or does the AIM
  46. benchmark measure reliability in addition to or instead of "speed"?
  47.  
  48. In my opinion, the biggest single defect of the SPEC LADDIS effort is
  49. that measurements of "speed" have not been sufficently separated from
  50. considerations of "reliability".  Both issues are of vital importance,
  51. but require very different techniques to quantify and are quantified in
  52. entirely different units.
  53.  
  54.  
  55. Vernon Schryver,  vjs@sgi.com
  56.