NFS against UDP

Till Straumann strauman at
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
  using NFS.

- 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

-- Till
> Many thanks for any comment/help.
> -- 
> Leon
> ------------------------------------------------------------------------
> _______________________________________________
> rtems-users mailing list
> rtems-users at

More information about the users mailing list