From: Steve Dickson <SteveD@redhat.com>
To: trond.myklebust@fys.uio.no
Cc: "Lever, Charles" <Charles.Lever@netapp.com>, nfs@lists.sourceforge.net
Subject: Re: [PATCH] Timeouts gone wild on ia64
Date: Thu, 15 May 2003 11:33:00 -0400 [thread overview]
Message-ID: <3EC3B32C.6000900@RedHat.com> (raw)
In-Reply-To: <16067.42148.524146.39488@charged.uio.no>
Trond Myklebust wrote:
>With a properly implemented algorithm, the number of retransmits
>should be small anyway as it is supposed to take into account the
>variance on the estimated RTO. We don't want any extra artificial
>limits if we can avoid it.
>
I totally greed... But this change, IMHO, will give a better estimated RTO
since all of the constants are based on the machine's HZ... At
least that's how I saw it...
>You may well be right in asserting that we're setting the initial RTO
>estimate too low, but then the answer should be to increase the value
>of the 'timeo' mount parameter as that is what defines the initial
>estimate.
>The default value of 'retrans' should also be looked at. I'm not at
>all comfortable with a default retrans value of '3' when doing soft
>mounts.
>
This was the direction I was headed until I saw the minimal RTO was
not HZ based... When I changed that which seem to take care of the
problem... I just stopped there... :(
>At the moment I believe that the default values for these 2 parameters
>differ in the kernel from those in the 'mount' program. IMHO, the
>mount program is overriding the kernel with too low values. It would
>be better if 'mount' did not set timeo/retrans (unless the user
>overrides) and left that to the kernel.
>
This definitely seems wrong....
SteveD.
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2003-05-15 15:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-15 5:46 [PATCH] Timeouts gone wild on ia64 Lever, Charles
2003-05-15 14:10 ` Steve Dickson
2003-05-15 14:31 ` Trond Myklebust
2003-05-15 15:33 ` Steve Dickson [this message]
2003-09-17 4:14 ` Yusuf Goolamabbas
2003-09-17 13:46 ` Trond Myklebust
2003-09-18 7:03 ` Yusuf Goolamabbas
2003-09-18 12:13 ` Trond Myklebust
-- strict thread matches above, loose matches on Subject: below --
2003-05-15 15:34 Lever, Charles
2003-05-15 14:26 Lever, Charles
2003-05-15 14:41 ` Trond Myklebust
2003-05-15 15:16 ` Steve Dickson
2003-05-09 15:24 Lever, Charles
2003-05-09 17:19 ` Steve Dickson
2003-05-09 13:40 Lever, Charles
2003-05-09 14:12 ` Steve Dickson
2003-05-09 12:41 Steve Dickson
2003-05-10 13:50 ` Trond Myklebust
2003-05-15 0:34 ` Steve Dickson
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=3EC3B32C.6000900@RedHat.com \
--to=steved@redhat.com \
--cc=Charles.Lever@netapp.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox