Messages in this thread | | | Date | Mon, 22 Jan 2001 14:37:40 -0800 | From | "H . J . Lu" <> | Subject | Re: [NFS] [CFT] Improved RPC congestion handling for 2.4.0 (and 2.2.18) |
| |
On Thu, Dec 14, 2000 at 03:16:36PM +0100, Trond Myklebust wrote: > > Hi, > > One of the things we've been lacking in the Linux implementation of > RPC is the 'ping' routine. The latter is used on most *NIX > implementations in order to test whether or not the RPC server is > alive. To do so, it simply calls procedure-0 (the NULL procedure), > which is always set up to return the value 0 and therefore acts more > or less like the icmp 'ping'. > > The appended patch implements such a routine, and uses it to improve > our congestion control, by allowing the entire set of pending requests > to inquire whether or not the server is alive, and then to sleep for 5 > seconds before retrying. This is done if and only if we get a major > RPC timeout and we see that the client Van Jacobson congestion control > can no longer throttle back the number of pending requests. > > This is more accurate than the current system of just retrying each > request, and waiting for 5 seconds if icmp fails, because the ping > directly tests whether the server is up and responding to > requests. Furthermore, unlike the retried requests, the packet length > of a ping request is always short, so we don't fall prone to issues of > udp fragmentation messing up the test. Finally, because all pending > requests are made to wait on a single ping rather than bombarding the > server with retries, it avoids further congestion to the network.
I got a report which indicates it may not be a good idea, especially for UDP. Suppose you have a lousy LAN or NFS UDP server for whatever reason, some NFS/UDP packets may get lost very easily while a ping request may get through. In that case, the rpc ping may slow down the NFS client over UDP significantly.
H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |