Re: [PATCH] Timeouts gone wild on ia64

[Yusuf Goolamabbas <yusufg@outblaze.com>]

> >>>>> " " == Steve Dickson <SteveD@redhat.com> writes:
> 
>      > It appears the RTO code does seem to be working but when the
>      > minimums start so low (like at 4m instead 40ms) it takes some
>      > time for the timeout value to build up and with soft mounts
>      > there is no time...
> 
>      > Maybe I'm missing something... increasing the timeout value
>      > should not have any affect on performance since in a well tuned
>      > client and server these timeout will never occur since the
>      > responses from the server will be returned before the timeout
>      > expires... right? Also decreasing the number of timeouts will
>      > decrease the number of retransmits which is another good
>      > thing... True?
> 
> 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.
> 
> 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.
> 
> 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.

Trond, In your opinion. What should be the default retrans value given
your recent work in having adaptive timeouts in the NFS client ?

Regards, Yusuf



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs