On Jan 29, 2008, at 3:50 PM, Matthew Toseland wrote: > On Tuesday 29 January 2008 21:24, Robert Hailey wrote: >> >> On Jan 29, 2008, at 1:40 PM, Matthew Toseland wrote: >>> What is the main reason for not accepting >>> requests from slow nodes? >> >> Because beyond a threshold they are most likely severally overloaded, >> or have such network latency that the hard-coded timeouts for freenet >> would not work (if only for the cause of this measurable latency). > > Yes but we are handling the request, so if we complete it, we send > it back to > them ... it might timeout on their side due to slow transfers or > something?
Statistically, they are forwarding the request, so I guess this amounts to our node saying they shouldn't have taken it on. >> More importantly though, we should not route request *to* them, and >> this is presently done only after a timeout (accepted/sendSync/fatal/ >> etc.). > > You think we should consider the ping time directly? This might make > sense... Sort of like the conditionalSend() patch... and I still haven't found where we reject all requests from a peer whose ping is >3s. >> These are two sides of the same coin. For an overloaded node (with >> all >> the ping times quite high), the effect is expected to be about the >> same; the slow-node is expected to reject requests in any event. > > Long term the expectation is that the slow node recognises it is > slow and only > asks for a few requests. But then it wouldn't be so overloaded, so > this > mechanism would be bypassed. Makes sense. >> Overall averaging suffers from: >> - odd calculation variances w/ backed off peers (as backed off peers >> are not counted for some reason) > > Because we already know they are overloaded? Do we? For the predominate backoff cause (RejectOverload), yes. For which case the ping time is generally small (they told us of the rejection). For AcceptedTimeout, the ping might be high. For FatalTimeout, etc... it is more likely that some-node-towards-that- location is overloaded. I do not see any general trend among my peer nodes, that is, backed off peers having higher ping times. What I see is that there are many low (25-300) and several high (3000-8000). >> - disproportionate statistics when running w/ few peers > > True. > >> (or not counting 'self' ping time) > > Huh? As a measure of cpu usage, how long does it take for us to send a message to ourself (unsupported). > >> - (as per above) possible cut off of all traffic > > Not due to a single node - the median would have to be high. Median of connected peers, but yes. >> Per-node suffers from: >> - Unsmoothed/jittery rejection rates (at least, as presented) > > Possibly yes. > >> - Unfairly rejecting local traffic > > Yes: different accept/reject logic for local requests. Which is bad > for > security reasons too. Originally this mechanism was simply a proxy for > directly measuring CPU load (because we can't do that). > >> - possible cut off of all traffic to/from a particular node > - different accept/reject logic for each peer. Okay, we already have > this to a > degree because of the send queue vs send rate logic, but even more > so. IMHO > this is bad if it can be avoided without too much impact on load > management. I see. -- Robert Hailey
