On Thu, Dec 14, 2000 at 05:06:23AM +1100, Luke Mewburn wrote:
> 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'.

Depend on what your "real world" is. Most of my NFS client are workstartions,
for which a single threaded benchmark is close enouth.

> 
> 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.

This doesn't explain why raw thoughput of TCP mounts is much higther than
UDP (A solaris client writes at 7MB/s to my NetBSD server with UDP mounts,
and 11MB/s with TCP).

> 
> 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.

On the server side, maybe. This is interesting when the bottleneck
is the server, which is not the case in my environements (and I guess
many others).

> 
> 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.

In *my* real world applications it's faster.

> 
> 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.

which shows that SPECSFS isn't a that good benchmark :) NFS v3 gives
a real boost for things like compiling a kernel on a NFS disk.

--
Manuel Bouyer <bouyer@antioche.eu.org>
--