NFS Write Performance

[Mathew Rippa]

Hi Till,

Thanks for the help. Just what I need for now.

-Matt

-------- Original Message --------
From: Till Straumann
Sent: Thu, May 10, 2012 05:27 PM
To: Chris Johns
CC: rtems-users at rtems.org
Subject: Re: NFS Write Performance


Very high performant NFS clients use techniques like caching,
read-ahead and delayed write-back (I remember the days when
linux only had decent read performance - it had read-ahead
but essentially synchronous writes [which were slow]).

The RTEMS client only implements synchronous operations
(I felt that caching, read-ahead etc. should be the job of
another layer, e.g., the bdbuf facility, which when I first
implemented the NFS client was not in a good state).

You can get the best out of NFS if you transfer large blocks.
The block size is limited by the NFS protocol (version 2) to 8k.

If you use stdio then the buffer size should probably be 8k.

The NFS client reports a st_blksize of 8k by default (fstat())
and newlibc uses this with reasonably recent RTEMS
(since 2009-02-24 RTEMS configures newlib defining HAVE_BLKSIZE).

More information is in

cpukit/libfs/src/nfsclient/README

This also contains a few performance figures which I restate
here (the code is in cpukit/libfs/src/nfsclient/src/nfsTest.c):

Software: src/nfsTest.c:nfsReadTest() [data not
           processed in any way].
Hardware: MVME6100
Network:  100baseT-FD
Server:   Linux-2.6/RHEL4-smp [dell precision 420]
File:     10MB

Results:
Single threaded ('normal') NFS read, 1k buffers: 3.46s (2.89MB/s)
Single threaded ('normal') NFS read, 8k buffers: 1.31s (7.63MB/s)
Multi  threaded; 2 readers, 8k buffers/xfers:    1.12s (8.9 MB/s)
Multi  threaded; 3 readers, 8k buffers/xfers:    1.04s (9.6 MB/s)

Consult the README to understand what the 'multi threaded' code
does.

HTH
-- Till


On 05/10/2012 09:39 PM, Chris Johns wrote:
> On 11/05/12 10:59 AM, Matt Rippa wrote:
>> Hi,
>>
>> I'm trying to compare in rough numbers the speed of writing a 50
>> MB file from RTEMS to an NFS mount. In VxWorks 5.5.1, one of our
>> detector systems is taking 21 seconds to write a file of this
>> size to an NFS mount. WindRiver claims the performance is better
>> in workbench 6.3.
>>
>> On Linux of course this is very fast, roughly 2 seconds on our
>> gigabit network. Sorry I don't have an RTEMS system up and
>> running or I already would have done some tests.
>>
>> Thanks for any insight,
>>
>
> It is difficult for RTEMS to quote numbers because the range of hardware
> that can be used varies widely and this will effect performance.
>
> The performance will also depend on the set up of the NFS client, ie the
> amount of buffer space you have configured.
>
> Where is the 50M of data being stored ?
>
> Chris
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users

_______________________________________________
rtems-users mailing list
rtems-users at rtems.org
http://www.rtems.org/mailman/listinfo/rtems-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20120511/e3bf09b0/attachment-0001.html>