Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!icdoc!qmw-cs!liam
From: liam@cs.qmw.ac.uk (William Roberts)
Newsgroups: comp.unix.aux
Subject: DMA Ethernet useless for NFS
Summary: NFS is *disk bound* and Ethernet is fine.
Keywords: NFS, nhfsstone, DMA, SCSI
Message-ID: <1837@sequent.cs.qmw.ac.uk>
Date: 26 Mar 90 19:49:37 GMT
References: <2323@husc6.harvard.edu> <1990Mar23.071213.6943@brutus.cs.uiuc.edu>
Reply-To: liam@cs.qmw.ac.uk (William Roberts)
Organization: Computer Science Dept, QMW, University of London, UK.
Lines: 63
Expires:
Sender:
Followup-To:
Distribution:

In article <1990Mar23.071213.6943@brutus.cs.uiuc.edu> coolidge@cs.uiuc.edu writes:
>(And, speaking of the fx, what's the chance of a DMA ethernet card? In a
>NFS environment, that's more important than DMA disks...).

This is a misconception: the limiting factor on NFS is disk
performance, not Ethernet performance.

To demonstrate this, consider the following version of the
nhfsstone benchmark: take nhfsstone, give it a mix of
operations which is 100% fsstat operations (i.e. it never goes
to disk at all) and compare your servers (based on a Sun 3/60
client). Nhfsstone tries very hard indeed to get the actual
server load (in calls per minute) that you ask for, so use a
Sun 3/60 with 6 worker processes and ask for 1000 calls per
second.

The results you get are:

-------------------------------------
This particular mix is the nearest I can manage to null calls:
the fsstat information is what "df" displays, and it is taken
from the superblock information for the filesystem (at the
server end). The superblock for a mounted filesystem is locked
into memory anyway, so no disk activity is involved.

For this test I ask for a target load of 1000 calls per second
over a total of 10000 calls.

SparcStation            266.84, 266.50
Sun 3/80                280.72, 281.38, 280.00
SparcServer 330         279.72, 278.52, 278.61  (Sun 3/60 client)
SparcServer 330         202.18, 201.14          (Sun 3/80 client)
Sequent                 182.45, 187.68
Mac IIcx + Racet        258.05, 257.15
Sun 3/50 + 141          218.21

These numbers say what they ought to say, namely that raw
processor speed is important for the business of handling,
decoding and replying to network packets.

There is also an implication that the Sun 3/80 can't generate
more than 200 fsstat requests per second, which could well mean
that 280 is the upper limit on the Sun 3/60.
-------------------------------------

So there you have it folks - Mac IIcx Ethernet performance
under A/UX 1.1.1 is pretty close to that of a Sparcstation. It
will surprise no-one to know that without DMA SCSI hardware and
using those ghastly Apple HD 80SC disks and a 1k block System V
filestore, the performance of a IIcx on the default nhfsstone
mix of operations is only about 1/5th of that of a Sparcstation.

PS. For what it's worth, the X11R3 that our Sun salesman found
as a part of his bid for 90 Sun 3/80s against 90 Mac IIcx was
slower on a number of the more important elements of the xperf
tests - it also seemed faster while you were sitting in front
of it.
-- 

William Roberts                 ARPA: liam@cs.qmw.ac.uk
Queen Mary & Westfield College  UUCP: liam@qmw-cs.UUCP
Mile End Road                   AppleLink: UK0087
LONDON, E1 4NS, UK              Tel:  01-975 5250 (Fax: 01-980 6533)