On Thursday 24 January 2008 20:36, Robert Hailey wrote: > > On Jan 24, 2008, at 2:00 PM, Matthew Toseland wrote: > > >> Well, in this case it was a reliable indication that one of our peers > >> maybe being overloaded (or defunct); and supposing that this node > >> appears consistently bad to all it's peers, then as a whole the > >> network does route around this node, but at one-extra-peer radius (it > >> does so because my node is rejecting requests in his favor). > > > > Definition of median: line up all the numbers in order and pick the > > middle > > one. One very high or very low value therefore has no or marginal > > influence > > on a median, if the others are unchanged. > > > > So if one of your peers is severely overloaded, that should have no > > effect > > whatsoever on your pInstantReject. > > Unless, I suppose, there was an instant when it was the only not- > backed-off peer; then it would average in real quick. > > More plausible since (1) these slow peers show up as NOT backed off, > and (2) being in this situation makes your peers backoff from you (is > a request reject more likely then?).
That is certainly possible... What's the fix? Take out the temporal averaging? Or only apply it if the number of peers is over a certain number? I don't like dropping the mechanism completely, historically ping time has proven to be a good general load indicator (for example it tends to go way high if there is a major CPU problem, because the threads involved are starved of CPU and therefore get longer ping times). -------------- 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/20080124/932dd636/attachment.pgp>
