<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<p style="color:#000000">Hi Till,<br>
<br>
Thanks for the help. Just what I need for now. <br>
<br>
-Matt<br>
<br>
-------- Original Message --------<br>
From: Till Straumann <br>
Sent: Thu, May 10, 2012 05:27 PM<br>
To: Chris Johns <br>
CC: rtems-users@rtems.org<br>
Subject: Re: NFS Write Performance<br>
<br>
</p>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Very high performant NFS clients use techniques like caching,<br>
read-ahead and delayed write-back (I remember the days when<br>
linux only had decent read performance - it had read-ahead<br>
but essentially synchronous writes [which were slow]).<br>
<br>
The RTEMS client only implements synchronous operations<br>
(I felt that caching, read-ahead etc. should be the job of<br>
another layer, e.g., the bdbuf facility, which when I first<br>
implemented the NFS client was not in a good state).<br>
<br>
You can get the best out of NFS if you transfer large blocks.<br>
The block size is limited by the NFS protocol (version 2) to 8k.<br>
<br>
If you use stdio then the buffer size should probably be 8k.<br>
<br>
The NFS client reports a st_blksize of 8k by default (fstat())<br>
and newlibc uses this with reasonably recent RTEMS<br>
(since 2009-02-24 RTEMS configures newlib defining HAVE_BLKSIZE).<br>
<br>
More information is in<br>
<br>
cpukit/libfs/src/nfsclient/README<br>
<br>
This also contains a few performance figures which I restate<br>
here (the code is in cpukit/libfs/src/nfsclient/src/nfsTest.c):<br>
<br>
Software: src/nfsTest.c:nfsReadTest() [data not<br>
processed in any way].<br>
Hardware: MVME6100<br>
Network: 100baseT-FD<br>
Server: Linux-2.6/RHEL4-smp [dell precision 420]<br>
File: 10MB<br>
<br>
Results:<br>
Single threaded ('normal') NFS read, 1k buffers: 3.46s (2.89MB/s)<br>
Single threaded ('normal') NFS read, 8k buffers: 1.31s (7.63MB/s)<br>
Multi threaded; 2 readers, 8k buffers/xfers: 1.12s (8.9 MB/s)<br>
Multi threaded; 3 readers, 8k buffers/xfers: 1.04s (9.6 MB/s)<br>
<br>
Consult the README to understand what the 'multi threaded' code<br>
does.<br>
<br>
HTH<br>
-- Till<br>
<br>
<br>
On 05/10/2012 09:39 PM, Chris Johns wrote:<br>
> On 11/05/12 10:59 AM, Matt Rippa wrote:<br>
>> Hi,<br>
>><br>
>> I'm trying to compare in rough numbers the speed of writing a 50<br>
>> MB file from RTEMS to an NFS mount. In VxWorks 5.5.1, one of our<br>
>> detector systems is taking 21 seconds to write a file of this<br>
>> size to an NFS mount. WindRiver claims the performance is better<br>
>> in workbench 6.3.<br>
>><br>
>> On Linux of course this is very fast, roughly 2 seconds on our<br>
>> gigabit network. Sorry I don't have an RTEMS system up and<br>
>> running or I already would have done some tests.<br>
>><br>
>> Thanks for any insight,<br>
>><br>
><br>
> It is difficult for RTEMS to quote numbers because the range of hardware<br>
> that can be used varies widely and this will effect performance.<br>
><br>
> The performance will also depend on the set up of the NFS client, ie the<br>
> amount of buffer space you have configured.<br>
><br>
> Where is the 50M of data being stored ?<br>
><br>
> Chris<br>
> _______________________________________________<br>
> rtems-users mailing list<br>
> rtems-users@rtems.org<br>
> <a href="http://www.rtems.org/mailman/listinfo/rtems-users">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
<br>
_______________________________________________<br>
rtems-users mailing list<br>
rtems-users@rtems.org<br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-users">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
</div>
</span></font>
</body>
</html>