On Tuesday 29 January 2008 22:35, Robert Hailey wrote: > > 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.
I'm not convinced - why can't we *accept* requests from slow nodes? > > >> 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. Ok. > > >> 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. Ideally all backoffs would be the result of preemptive rejection i.e. RejectOverload. But maybe it would be better to include backed off nodes. > > 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). So the median should be around 300. > > >> - 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. Well is cutting off all traffic such a bad thing in this case? Isn't it the expected and justified behaviour? In practice, when a node gets a ping spike, it can take a very long time for it to recover - I've partly addressed this by making the averagers 2.5x more sensitive in trunk... > > >> 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. The question is, does it make a big difference? It would be preferable to retain the global ping mechanism for the above reason, but we can get rid of it if it is vital. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080130/b4a70814/attachment.pgp>
