From: mc@emma.la.asu.edu (Mike Caplinger)
Subject: benchmarks for Sun NFS accelerators
Organization: Mars Observer TES Project, ASU, Tempe AZ
Date: Thu, 3 Sep 1992 17:56:07 GMT

This message describes my recent benchmarks of NFS accelerator
products for Sun SPARC computers.  It is not an endorsement of any
specific product, and like all benchmarks, is obviously dependent on
the application.  Most of our applications are image processing
programs that read one or more files (some sequentially, some
randomly) and write a result file, usually sequentially.  These files
are often tens or even hundreds of megabytes in size.  We usually use
mmap to map the files in their entirety into memory, both for input
and output, and we always map shared so as to not use swap file space.

Originally, we had intended to require local disk space on each
workstation to store output files temporarily, because we knew NFS
writing performance was poor.  However, this approach is a pain to
administrate (no one's local disk is ever big enough), so we wanted to
see what various NFS accelerators would do for our applications.

We wrote two simple benchmark programs to simulate the output phase of
our applications.  The first, called `write', does a single write
system call of a specified amount of memory.  The second, `map',
creates, extends, and then mmaps a file of a given size, then
sequentially touches the first byte of each page.

Two products were tried: eNFS from Interstream and Sun's SBus
Prestoserve (with 1 MB of NVRAM).  We ran eNFS in both normal and
asynchronous modes.  We compare the performance results against local
disk access; our goal was to find a solution that gave us performance
within a factor of two of local access.

The following results are for SBus Prestoserve versus local disk
access.  These numbers were obtained at the San Diego Sun office.
Remote operations were from an IPX with 32 MB and a 669MB disk to a
630MP with 64MB(?), an attached 1.2GB Seagate disk, and two
processors.  Local operations were to the IPX's 669MB disk.

file	presto	local	presto	local
size(MB)write	write	map	map
4	0:08	0:02	0:16	0:02
8	0:16	0:06	0:30	0:02
16	0:30	0:12	1:02	0:07
32	1:01	0:31	1:50	0:19

The following results are for eNFS in normal mode.  These numbers were
obtained at MSSS.  Remote operations were from an SS2 with 64 MB and
an HP 1GB to a 670MP with 64MB, an attached 2GB Micropolis, and four
processors.  Local operations were to the SS2's HP disk.

file	eNFS	local	eNFS	local
size(MB)write	write	map	map
4	0:15	0:03	0:49	0:01
8	0:30	0:05	1:39	0:01
16	1:06	0:10	3:22	0:03
32	2:33	0:29	6:35*	0:10

* We sometimes saw faster times by a factor of two for this number,
reason unknown, but it was never faster than about 3 minutes.

These numbers, also obtained with the MSSS configuration, are for eNFS
in asynchronous mode.

file	eNFS	local	eNFS	local
size(MB)write	write	map	map
4	0:06	0:03	0:11	0:01
8	0:12	0:05	0:23	0:02
16	0:23	0:11	0:47	0:03
32	0:56	0:29	1:19	0:13

This is a summary of the results for 32 MB output files, normalized to
local performance:

	local	presto	eNFS	eNFS async
write	1	2.0	5.3	1.9
map	1	5.8	39.5	6.1

Disappointingly, neither eNFS nor Prestoserve comes close to meeting
our requirements for the map benchmark.  This is probably inevitable,
given that the mapped pages are not written out to disk until the
system runs out of memory if the mapped object is local, but they
appear to be flushed when the process exits if the mapped object is
remote.  Once again, I wish that there was some way to specify the
reliability semantics of NFS operations on a per-partition or even a
per-file basis.  mmap is superior for local access, but seems to
overwhelm the available NFS accelerator products when pages are
flushed to remote objects (perhaps an artifact of the way SunOS
flushes pages?)

Any comments or questions are welcome.

	Mike Caplinger, MSSS/Caltech Mars Observer Camera Project
	mc@msss.com

disclaimer: this message contains the opinions of the author only, and
is not the official position of MSSS or any of its funding agencies.
Newsgroups: comp.protocols.nfs