NFS Write Performance
mrippa at gemini.edu
Fri May 11 05:25:52 UTC 2012
Thanks for the help. Just what I need for now.
-------- 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
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].
Server: Linux-2.6/RHEL4-smp [dell precision 420]
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
On 05/10/2012 09:39 PM, Chris Johns wrote:
> On 11/05/12 10:59 AM, Matt Rippa wrote:
>> 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 ?
> rtems-users mailing list
> rtems-users at rtems.org
rtems-users mailing list
rtems-users at rtems.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users