Summary of Auspex vs. 4/490 query

Date: Thu May 17 1990 - 12:52:33 CDT

I received only a few replies to my query about 4/490 performance
(with respect to the Auspex) but since there is general interest I
thought I'd post a summary.

It should first be noted that such a rough measurement of performance
as a limited run of "nfsstat" should not be the final guide in any
decisions about server performance. The following inclusion is from
Bruce Nelson (from Auspex) and succintly points out the problems with
using such a measure:

I'm also interested to know the results of your survey. But I would
not call computing a site's NFS load a benchmark. I'd call it
measuring a peak load independent of configuration or workload. Either
way, in trying to measure this myself I have encountered these issues:

If you ask for an NFSSTAT reading, you must want the duration too so
that you can compute both the average op rate in the interval as well
as the op mix. I see that you ask for this.

You are asking for call rates without response times. I know you
realize the trouble with this, especially since response times cannot
be easily measured with any sun tools. You might ask whether the
user-perceived response time (and not the server load average, which I
believe is a less worthy indication unless nearly idle) during the
"heavy" period is excellent, good, fair, poor, bad.

Doubling the offered client load will not increase the server NFSSTAT
reading if the server is already saturated. This is the same as
running a horse race with hobbled horses: you don't really find the
winner. I'm concerned that any site with "heavy" NFS use may be
offering more load than they can measure--we have often found this to
be the case. The only way I can see to consider this factor is to
query the user response time perception, and to add up the NFSSTATS
over many servers in larger sites to look a the total op rate.


With those caveats in mind, I have the following information. I'm not
providing names of sources since some of this is
political/controversial. The people who gave the information can step
forward if they wish, or I can contact them for anyone interested in
discussing this further. I'll also be interested in receiving
"reasonable" mail about any of this information. I don't think flames
are appropriate since I'm presenting this as "my perception and
opinion on the current systems from Auspex and Sun". I have not
actually touched either of these systems, but I do have a sore ear
(and sore typing fingers) to demonstrate the amount of time I've spent
talking with Sun, Auspex, and end users of both systems. I've culled
this information down to what I consider to be the most applicable and
demonstrable set of values.

To summarize my perception of their published benchmarks, they claim
about 120 iops at reasonable performance levels from each of 1-8
ethernet boards, or a total of 1000 iops.

I've spoken to 4 references provided by Auspex and they all seem happy
with their systems, but no one is using more than 4 ethernets and the
highest number of clients I've seen is about 50 diskless systems. The
one site I've been in close contact with did some measurements for me
and found that on 4 ethernets they've seen 300 iops with no noticible
degradation in performance (so it should be able to go higher).

I have yet to see an official published Sun NFS benchmark or
performance claim. The rough claim is "2-4X a 4/280". I've been
talking to a couple of Sun consultants/SEs and gotten some iops numbers
from them (although not published and less polished/complete than the
Auspex numbers) ranging from 80 through 183 iops from one ethernet.
The variation is probably attributable to the operation mix being used
(at 80 the write percentage was something like 60%, while at 183 it was
closer to 20%). Sun is also contending that the numbers will scale
with the number of ethernets and controllers/spindles installed on the
system, and if that is true 4 * 183 should be the ballpark (since
SunOS 4.1 allows 4 of each). These benchmarks were done under 4.0.3
but forthcoming numbers (hopefully next week) will be under 4.1.
Given that it is a well known fact (and we've seen it here) that 4/280
iops counts actually decreased when a second ethernet was added, the
question of scalability is an important one to resolve.

I only received one message from a user who had measured NFS iops, and
his number was around 80 on a 1 ethernet system. I'm still looking
for more data points if anyone in interested in testing their system.


Method: as a memory refresher, recall that I'm asking for the output
of nfsstat -z measured over a fixed, busy time period. The values
I've referred to here are from the "calls" field of the "Server nfs:"
section of the output. I'd also like server load average and
perceived "response time" feedback with any raw numbers.

Thanks for your input and I hope you find this information


------------------------------------------ --------------------------------
Peter Baer Galvin (401) 863-7623
Systems Manager, Brown Univ. Comp. Sci.
Box 1910 (115 Waterman Street) uunet!brunix!pbg
Providence, RI 02912 (02906) pbg@browncs.bitnet

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:57 CDT