On December 12, 2007, Robert Hailey wrote: > > On Dec 11, 2007, at 5:59 PM, Matthew Toseland wrote: > > Ok that could be interesting. Although ideally we'd have a > > circular-keyspace-aware averager. > >> ... > > Ok. I suggest you commit, I will review post-commit. > > Committed it r16508, though it has changed slightly according to my > experiments with swap-biasing (e.g. shows number of cache/store writes > as well).
Were should this appear? Does it take a while to show up? I have r16509 running and am not seeing anything new (yet). > From what I have discovered (or theorized) thus far, using the > average location of the entire store to bias against is way too much > of an anchor. This is good, because it takes up way to much memory to > remember such a running average anyway. If we end up implementing such > a bias, in the end, it will likely just take into account the last few > inserts or successes (a small constant amount). In this way, the > pressure of your peers can still pull you into a new location > (dragging the weight of the last few inserts with you; which will be > updated). Keeping the average key location and standard deviation just requires a few counters along hooks to update them when adding or deleting the store... It also requires a single pass to get the initial numbers. Should not be expensive except for that first pass. I agree that using the average would be very restrictive. Average plus or minus standard deviation would give a much better 'limit'. I suspect that It would take a fair length of time for it to start limiting at all (e.g. 2 x standard deviation would be greater than 1). > Whereas previously I have seen the 'storeDistance' to be 0.065 (IIRC), > after running with a recently-stored-location bias, I must have pulled > my peers closer to me as well, as now even with the patch off, I do > not see the storeDistance go nearly so high (staying around 0.004). > Or, since the network has no anchor, maybe I've pressured the whole > wheel to stop turning. For at least my node; this (valuing the store > as one peer) has not shown any increase in store hit rates, biasing > against the succeeding requests, however, has in the past raised it to > about 1%; but I would be even more concerning with implementing that. > > With these stats I have noticed what may be an odd constant-location- > shift between what the node is requested to insert and retrieve, like > the network does not look for data in the exact same place it stores > it?!?!?! Suspect, but still can't confirm anything yet. Ed
