All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H . J . Lu" <hjl@valinux.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	NFS maillist <nfs@lists.sourceforge.net>
Subject: Re: [NFS] [CFT] Improved RPC congestion handling for 2.4.0 (and 2.2.18)
Date: Mon, 22 Jan 2001 14:37:40 -0800	[thread overview]
Message-ID: <20010122143740.A31589@valinux.com> (raw)
In-Reply-To: <14904.54852.334762.889784@charged.uio.no>
In-Reply-To: <14904.54852.334762.889784@charged.uio.no>; from trond.myklebust@fys.uio.no on Thu, Dec 14, 2000 at 03:16:36PM +0100

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/

  reply	other threads:[~2001-01-22 22:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-14 14:16 [CFT] Improved RPC congestion handling for 2.4.0 (and 2.2.18) Trond Myklebust
2001-01-22 22:37 ` H . J . Lu [this message]
2001-01-22 23:00   ` [NFS] " Trond Myklebust
2001-01-22 23:36     ` H . J . Lu
2001-01-24 18:19       ` H . J . Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010122143740.A31589@valinux.com \
    --to=hjl@valinux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nfs@lists.sourceforge.net \
    --cc=trond.myklebust@fys.uio.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.