NFS Performance

[Till Straumann]

Hi Steven.

Thanks for your report. Let me elaborate a bit:
Since there is no buffer cache with read-ahead implemented,
all NFS reads are synchronous RPC calls. Every read operation
involves sending a request and waiting for the reply. As long
as the overhead (sending request + processing it on the server)
is significant compared to the time it takes to transferring the
actual data, increasing the amount of data per request results
in better throughput. The UDP packet size limit imposes a
limit of 8k per RPC call, hence reading from NFS in chunks
of 8k is better than chunks of 1k [but chunks >8k are not
possible, i.e., simply not honoured: read(a_nfs_fd, buf, 20000)
returns 8192]. This is similar to the old linux days (mount with
rsize=8k).
You can let stdio take care of the buffering or use 8k buffers
with explicit read(2) operations.

Further increase of throughput can be achieved with read-ahead
(issuing RPC calls in parallel [send out request for block n+1
while you are waiting for data of block n to arrive]).
Since this is not handled by the file system itself, you would have to
code this yourself e.g., using parallel threads to read from a single 
file from
interleaved offsets.

Another obvious improvement can be achieved if processing
the data takes a significant amount of time. Then, having
a pipeline of threads for reading data and processing them makes
sense [thread b processes chunk n while thread a blocks in
read(chunk n+1)].

-- Till

Steven Johnson wrote:
> Hi,
>
> We are using the NFS Client stack as found in the RTEMS CVS.  We
> experienced the slow performance that the readme talks about.  We were
> getting around 3.5Mbit/s on a 100MBit link.  Our Processor is a 100Mhz
> MPC862, and we are using the FEC.
>
> This isn't fast enough for us, as we need around 6-7 Mbit/s so we can
> read media files and play them in real time from the NFS Share.
>
> So we investigated the causes.
>
> The single biggest thing we found is BUFSIZ in stdio.h.
>
> It was defined as 1024, which gave us ~3.5Mbit/s
> We Changed it to 8192, and NFS Performance on our board jumped to
> ~19.53MBit/s
> We also tried 32768, which gave us ~19.99MBit/s
>
> (This is all Read performance, we don't know how fast write is, because
> we don't write with our application).
>
> Also, the readme for the NFS Client indicates performance sucks due to a
> lack of read ahead buffering.  Changing BUFSIZ to 8192 seems to provide
> read ahead buffering, because if we read 512 bytes, 8192 bytes are
> transferred from the file, and another request for 8192 bytes only
> occurs when we have exhausted that data.
>
> Anyway, I'm just reporting this so that anyone else who needs NFS to
> perform better can know what we did to achieve dramatic speed increases.
>
> Steven J
>