*BSD News Article 61175


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!olive!navmat.navy.gov.au!posgate!posgate.apana.org.au!posgate.acis.com.au!news.act.apana.org.au!warrane.connect.com.au!news.syd.connect.com.au!news.mel.connect.com.au!harbinger.cc.monash.edu.au!nntp.coast.net!news.kei.com!newsfeed.internetmci.com!info.ucla.edu!library.ucla.edu!galaxy.ucr.edu!corsa!grif
From: grif@corsa.ucr.edu (Michael Griffith)
Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system,comp.benchmarks,comp.protocols.nfs
Subject: NFS performance:  What am I doing wrong with FreeBSD?
Followup-To: poster
Date: 9 Feb 1996 18:54:44 GMT
Organization: UC Riverside, Dept. of Computer Science
Lines: 67
Distribution: inet
Message-ID: <4fg59k$fmp@galaxy.ucr.edu>
NNTP-Posting-Host: cs.ucr.edu
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:13618 comp.os.linux.development.system:17119 comp.benchmarks:11291 comp.protocols.nfs:13371

I've heard from "far and wide" about how studly FreeBSD's NFS
performance is.  Unfortunately, I have not been able to reproduce it.
Any hints?  Here are the benchmarks that I ran.  In nearly every case,
the Linux box (with twice the RAM, but a sorry ethernet card, and some
load) performed better than FreeBSD.  

I realize the tests aren't fair because the hardware and load varies,
but I still feel that I may be doing something else wrong with FreeBSD. 
I am not trying to detract from FreeBSD, I just want to know how
to make it be a fast NFS server.  Right now, it comes in third.

BTW, the Indy with its `cheating' technique of doing async NFS
performs very,very well.

		corsa,highload	razo,noload	hill,lowload	squire,highload
		Sun SS1000	P5-120		P5-120		SGI Indy
		SunOS 5.5	FreeBSD-2.1	Linux-1.3.55	IRIX 5.3
		256M RAM	32M RAM		64M RAM		32M RAM
		lance		3c509		NE2000		?	
-------------------------------------------------------------------------------

nfsstone(+)	153		162		200		226

write sml (-)	0.80		0.35		0.18		0.16
write med (-)	2.0		1.2		0.9		0.7
write lrg (-)	31		16		12		8

zcat+tar (-)	12		8		4		4
compile (-)	357		391		87		77
compile -j8 (-)	192		373		51		51

nfsbench(user+system):
mkdir (-)	0.11+0.02	0.11+0.00	0.12+0.00	0.11+0.00
rmdir (-)	0.00+0.01	0.00+0.00	0.01+0.00	0.00+0.01
creat (-) 	0.10+0.54	0.20+0.52	0.10+0.55	0.19+0.24
write (-)	0.16+1.41	0.15+1.21	0.16+1.20	0.15+1.23
read (-)	0.16+0.74	0.17+0.72	0.20+0.82	0.17+0.77
mkdir rec (-)	0.24+0.34	0.14+0.21	0.13+0.22	0.14+0.15
lookup rec (-)	0.21+0.66	0.25+0.49	0.16+0.60	0.21+0.76
rmdir rec (-)	0.56+1.03	0.58+0.70	0.71+0.87	0.74+1.00

-------------------------------------------------------------------------------

(+) = bigger is better
(-) = smaller is better

Client is: predator,noload   \
	   P5-120	      \   My test client is Linux because
	   Linux-1.3.59        >  75% of our client stations are.
	   32M RAM            /   Your results may vary.
	   NE2000            /
	   rsize=8192       /
	   wsize=8192      /

I realize that LADDIS/SFS may be the better way to go, but don't have
it yet.  The nfsstone/nfsbench numbers may not be too useful, but I
feel that the natural benchmarks of zcat+tar, compile, and compile
with make -j8 (to build GNU cpio-2.4.2) are quite representative of
the type of work my users do.

I would appreciate any comments and pointers to FREE benchmarks.

-- 
Michael A. Griffith (grif@cs.ucr.edu) | http://www.cs.ucr.edu/~grif/
Department of Computer Science        | PGP public key available.
University of California, Riverside   | "My freedom of speech implies
(909) 787-3803                        |  your freedom to be offended."