From: beepy@ennoyab.Eng.Sun.COM (Brian Pawlowski)
Newsgroups: comp.protocols.nfs,comp.sys.sun.hardware
Subject: Re: NFS I/O Ops/seconds
Summary: nfs laddis nhfsstone
Date: 25 Jul 92 00:49:01 GMT
Followup-To: poster
Organization: Sun Microsystems Inc., Mountain View, CA
NNTP-Posting-Host: ennoyab

In article <12470@inews.intel.com>, mfineman@cadev5.intel.com ( Mark S. Fineman ) writes:
> In article <l6r4uvINNf0p@exodus.Eng.Sun.COM> beepy@tabitha.Eng.Sun.COM (Brian Pawlowski) writes:
> >...
> >The number "300 NFS ops/s per ether" is a rule-of-thumb
> >. . . 
> 
> From what I've heard from various people at various vendors of
> file servers the PRE-LADDIS OP/S are about 2 times the
> nhfsstone OP/S for equivalent mixes.
> 
>  150 or so would be fair for nhfsstone,
>  300 or so would be fair for PRE-LADDIS.
> 
>  340 using PRE-LADDIS and the equivalent mix to the default
>  mix in nhfsstone would be pretty good.  I don't think
>  you could get 340 using nhfssone and that mix.

Enter slippery ground, and take following with "a your mileage
may vary non-linearly" attitude:

1. The 300 ops/s maximum is the rule-of-thumb maximum for PRE-LADDIS
   and nhfsstone from Legato. 
   
   Of course, you will only see this if your server can handle
   300 or more ops/s, *and* your "load generating" clients can
   generate the load. And I have seen 325 ops/s on a single
   ethernet for at least one (of the many) versions of PRE-LADDIS
   I've evaluated.

2. If you feel your server can handle more load than 300 ops/s,
   you have two choices: (1) increase the number of low-bandwidth
   pipes feeding your server (ethernets) or (2) go to a higher
   bandwidth feed like FDDI.

   MTU characteristics and resulting NFS packet fragmentation
   (reduce fragmentation) will account for slight differences
   between a multi-ethernet server and one connected (directly)
   with something like FDDI. There are a couple of reasons
   for this, exercise left to the reader.

   [Remember PRE-LADDIS and nhfsstone measure the avg. response
   time of the server at a given load. Both numbers--maximum
   load and response time--are criticial to understanding server
   performance. That's a hint to anser above question.]

3. Not all network interfaces are created equal. The problems
   people have had with PC ethernet hardware springs to mind.

4. Another rule of thumb I use is that an SS2 or a DS5000 (which
   I've a little experience with in NFS benchmarking) can generate
   about 300 NFS Ops/s. In case any of you are doing this out
   there.

5. Legato's nhfsstone uses client NFS code to generate traffic and
   PRE-LADDIS does direct RPC calls. Their load generation seemed
   similar enough (when I did a comparison of pre-beta PRE-LADDIS
   and Legato nhfsstone 1.21 or 1.22).

   nhfsstone *from* Legato depends on the client NFS code to
   generate the NFS operations as a "side-effect" of file system
   operations. In one sense, you can say nhfsstone 1.x is
   "correct" since the load is actually generated by client NFS
   code.

   PRE-LADDIS has abstracted load characteristics (such as read/write
   request size) and performs the operations explicitly. In this case,
   the benchmark is client independent--the same load profile
   is presented to the server regardless of what client machine
   is used.

   Anyway though, recognizing that they're different, I don't
   believe there is a 2x difference in loading between the two.
   Everything I've seen and experiments I've run point to a 
   similarity of effect from the two load generating programs.

Take all this with a "I'll try it for myself at home" attitude.
And remember benchmarking is an art. We should all take art
lessons.

Brian Pawlowski
Newsgroups: comp.protocols.nfs