*BSD News Article 61877


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.OZ.AU!spool.mu.edu!howland.reston.ans.net!swrinde!sdd.hp.com!hamblin.math.byu.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: NFS performance:  What am I doing wrong with FreeBSD?
Date: 13 Feb 1996 03:43:22 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 63
Message-ID: <4fp1cq$art@park.uvsc.edu>
References: <4fg59k$fmp@galaxy.ucr.edu>
NNTP-Posting-Host: hecate.artisoft.com

grif@corsa.ucr.edu (Michael Griffith) wrote:
]
] 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.


Linux also cheats.  It's user mode NFS to an async FS underneath
not using O_WRITESYNC is triply in violation of the NFS protocol
specifications (if you wonder about this, go back and read the
ISP thread in comp.unix.bsd.bsdi.misc).

To be fair, allow BSD to lie to its clients like the other OS's.

I noticed BSD on the P5/120 beat the Solaris SS1000 box handily
in all but one category.  I suggest you turn of write gathering
(the administrative manual tells you what "debug" statement does
this) to force Solaris back to sync metadata updates as well, so
that it correctly obeys the "shall be updated" as well as the
"shall mark for update" POSIX semantics.


The memory comparison is unfair, with 32M more available for cache
on the linux box.

I would suggest making sure the number of nfsd's was rather large
on the BSD box.


You should also try to compare NFSv3 figures (since BSD supports
NFSv3.

The 3C509 is a known piece of crap because of the number of
outstanding buffers.  Use the same card in both machines.
Non-identical hardware is unfair.



Finally you don't identify the client type.  I suspect that the
client is a Linux machine?  This would correspond with the good
Linux-Linux numbers in the "Lai/Baker" paper out of Stanford
and presented at the last Usenix (prejudicially presented,
according to reports from attendees).

You won't be able to try the NFSv3 speedups with a Linux system
in any case, since it is not supported.


                                        Terry Lambert
                                        terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.