Subject: Re: CVS commit: basesrc
To: None <tech-net@netbsd.org>
From: Luke Mewburn <lukem@wasabisystems.com>
List: source-changes
Date: 12/14/2000 05:06:23
[moved from source-changes]

On Wed, Dec 13, 2000 at 12:17:20PM +0100, Manuel Bouyer wrote:
> On Wed, Dec 13, 2000 at 09:26:19AM +1100, matthew green wrote:
> >    
> >    Log Message:
> >    Now that the problem with TCP mounts is fixed, switch back to TCP mounts
> >    by default. This allows to kill the hack that was added to work around
> >    a problem with SunOS 4.x NFS servers.
> > 
> > 
> > hmmm.. isn't NFS over TCP slower?
> 
> Tests shows that it's faster (I don't remember on which list the discussion
> about this started - maybe port-i386), although I don't know why.
> On solaris, TCP mounts are faster too (and solaris also uses TCP mounts by
> default).

This is an interesting point.

In a single threaded single client `big copy', it's possible that TCP
with 32K block sizes will appear faster. Guess what type of benchmark
`bonnie' is? It's also why bonnie is a crap benchmark for anything
other than raw throughput; it is NOT good for testing the system
in a manner that is anything like a real world environment for most 
workloads, including `multiple clients (users/processes) all hammering
the one disk'.

The advantage of TCP mounts is that they're more resiliant on LANs or
WANs that are not `clean' (i.e, there's some lossage). The reason is
because TCP handles the packet assembly and will only retransmit the
1.5K packet that went missing, whereas UDP will retransmit the entire
8K or 32K packet.

To see the difference between TCP and UDP when running the SPEC NFS
benchmark - SPECSFS - which is supposed to be closer to real world
usage, check out:
	http://www.spec.org/osg/sfs97/results/res98q3/sfs97-980805-00005.html
	http://www.spec.org/osg/sfs97/results/res98q3/sfs97-980805-00006.html
These are for the same server (NetApp F740, which is a 400MHz 21164A
alpha based machine).
Notice that the UDP latency for a given transaction rate per second
is lower, and that the system can deliver more UDP ops/sec than TCP
ops/sec.

Now, it's unlikely anybody in the NetBSD community will be able to
afford SPECSFS for a while (although that may change in the future),
but there are other benchmarks that we can use to test our filesystems
(e.g, NFS, RAIDframe, etc) in a more realistic manner than bonnie.
NetApp has a benchmark called postmark (which not surprisingly makes
their systems look good because of their transactionaly acceleration
methods), and more info on that can be found at:
	http://www.netapp.com/tech_library/postmark.html

There's probably other benchmarks to consider as well.

In summary, NFS over TCP is slightly slower under most real world
situations, but it is more reliable and easier to tunnel than
NFS over UDP.

Note that NFS v2 is `faster' than NFS v3 on the SPECSFS benchmark
because it has lower overhead. There are benefits of running NFS v3
in the real world, such as support for > 2GB files and filesystems, etc.

Luke.

PS: I spent some time working for NetApp. I apologise if the
references to them seem excessive, but they do build one of the
fastest bang/$ NFS servers on the market...

-- 
Luke Mewburn  <lukem@wasabisystems.com>  http://www.wasabisystems.com
Luke Mewburn     <lukem@netbsd.org>      http://www.netbsd.org
Wasabi Systems - providing NetBSD sales, support and service.