NFS

[Scott Schoenthal]

In article <5491 at spool.cs.wisc.edu> dave at spool.cs.wisc.edu (Dave Cohrs) writes:
>A nitpic: NFS, as used on most machines, uses UDP/IP.  TCP is too slow
>and is stateful.  I'm know there are other NFS implementations (Lachman
>did/is doing one over ISDN).  Nothing in NFS itself assumes that it
>uses UDP.  The biggest problem I would see with using a X.25 is that
>X.25 is stateful, which would probably make NFS slower.

Please don't confuse the "statelessness" of the NFS server implementation with
the class (sp., connection-oriented, connectionless) of the underlying
transport.

Opinion:

Using NFS over an unreliable link (e.g, not a friendly Ethernet/802.3 LAN)
would probably require some lower-level connection-oriented
service.  Sun's NFS/RPC, in its kernel implementation, is geared toward a
"reliable" unreliable transport.  That is, while UDP/IP is connectionless,
the Ethernet is a moderately reliable physical link and, disregarding
overruns, etc., at the server (or gateways, bridges), most packets will get
through.  On the other hand, NFS/RPC performance degrades significantly when
the link becomes lossy.

The problem with X.25 is not that it is stateful, just that it is slow(er).
Grabbing a 4Kbyte block from a remote system is a mighty big difference when
performed over a 56kb line versus over an Ethernet at essentially Mbit rate.

In addition, adjusting NFS call timeouts is an art: most people I've talked
to pick an arbitrary value and then tinker with it until it seems right.  In
the current implementation of kernel RPC, there is no "smoothing" function
which could adjust the timeouts based upon previous experience calling to a
particular host.

sas
----
Scott Schoenthal   sas at pyrps5.pyramid.com	Pyramid Technology Corp.