[mnet-devel] Re: [mnet-cvs]calculate timeouts according to size of sent message

Arno Waschk hamamatsu at gmx.de
Tue Feb 17 01:23:58 GMT 2004


put block is either 64kB but much, much smaller for those sharemap blocks, 
no?
Arno

On 16 Feb 2004 20:13:57 -0500, Zooko O'Whielacronx <zooko at zooko.com> wrote:

>
> -def calculate_timeout(mu, sigma):
> -    return mu + 3*sigma
> +def calculate_timeout(mu, sigma, size=500):
> +    return (mu*size/500) + sigma)
>
>> yes, but initiating messages can be 250 bytes or very big ("put block",
>> "message for you").
>
> "put block" should be handled fine by the traditional statistical 
> timeout, since
> "put block" messages are always the same size.  You're right about 
> "message for
> you".
>
>> This was why it was introduced in 0.7. Should at least help in these
>> cases, and not hurt anywhere else...
>
> Well, I'm not so sure that it won't hurt.  The new version doesn't 
> increase for
> variance as much as the old, which means that we'll get more timeouts on
> messages which vary more.  For example, "are there messages" varies a 
> great deal
> due to the size of the response, and so this patch *might* cause 
> "preferred
> relay server churn", where there usually isn't a message when you ask 
> "are there
> messages", so the mu is small, but then whenever there *is* a message 
> you get a
> timeout and start to prefer a new relayer.  Hopefully that won't happen 
> because
> of the late responses and the "stick with current relayer" handicapper, 
> but
> I'm not perfectly sure it won't cause that kind of problem either in 
> relayer or
> somewhere else.
>
> On the other hand, I don't think it helps much -- changing 
> calculate_timeout()
> is probably not really needed at this point, now that we have these 
> various
> recent fixes, especially the TCP linger close patch.  The only message 
> type
> where including the size of the message should make a big difference is 
> "message
> for you", and it doesn't make that much difference if a "message for 
> you" times
> out.  I *think* the worst that can happen is the underlying TCP 
> connection is
> closed and a new one re-opened.
>
> I didn't really like its addition to v0.7, for the same reasons.  (That 
> was
> Tschechow's idea in v0.7.)
>
> Regards,
>
> Zooko
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> mnet-devel mailing list
> mnet-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mnet-devel
>



-- 
http://www.arnowaschk.de


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
mnet-devel mailing list
mnet-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mnet-devel




More information about the Mnet-devel mailing list