NFS against UDP

[Leon Pollak]

On Wednesday May 6 2009, Till Straumann wrote:
> 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.
Thanks for the tip, I shall take this into account.
But most of the time we do writing, not reading...


> - 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.
Yes, but as i was able to understand from the last e-mails on the list, the 
Jumbo packets are not supported "out-of-the-box" today. Or am I wrong?


> - 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
>   buffer.
>   The behavior is compile-time configurable (nfsclient/src/rpcio.c)
>   -- by default a second copy operation is avoided.
Great. Where can I read about all this?


> -> 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
>     tests...
Can you say something about "writes"? I suppose the same, yes?

The last question - I need to be the NFS server (not client). Can you 
recommend something for this?

Till, thank you very much for your time.
-- 
Leon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20090506/d1b41fdf/attachment.html>