NFS against UDP
strauman at slac.stanford.edu
Wed May 6 09:30:27 UTC 2009
Leon Pollak wrote:
> Hello, all.
> I need a help from the list members, gurus in networking, as I am too
> weak in this.
> I have today an application under RTEMS speaking with another
> application via UDP. Most of the time data exchange via our simple UDP
> protocol is transferring big amounts of data, the rest are some commands.
> The amounts of data are so big (for the system) that most of the time
> CPU is processing the BSD stack operations.
> The customer now insists on introducing the NFS. I object, explaining
> my objection mostly by significant increasing of required CPU power
> and traffic to perform the NFS protocol.
> The question is - am I right? Do someone has a similar experience? How
> can I estimate the load growth even VERY roughly?
A few hints (NFS read operation only; write is very similar)
- rtems NFS implementation is fully synchronous (no read-ahead,
i.e., request block X, wait until block X received). Probably your
raw UDP communication is similar but if it does implement
read-ahead / caching then expect significant slowdown when
- For every block read, NFS requires XDR-decoding a protocol
header. This overhead is relatively small, especially if a large
block size is used (you want 8k / max. allowed by UDP). A large
block size also speeds up synchronous operation.
- The payload data is copied verbatim (w/o any byte-swapping
to the user's buffer). If the 'xdr_mbuf' stream is used then
the cost is similar to using normal UDP (copying from mbufs
into user buffer) -- otherwise data are copied twice (from
mbufs to NFS memory buffer, then again from there to user
The behavior is compile-time configurable (nfsclient/src/rpcio.c)
-- by default a second copy operation is avoided.
-> If you use a large block size, read relatively large files
(>> NFS protocol header) and your current implementation
does not implement read-ahead/caching then I'd be surprised
if NFS is a lot slower. Nevertheless, you want to run a few
> Many thanks for any comment/help.
> rtems-users mailing list
> rtems-users at rtems.org
More information about the users