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). 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). 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. -- Robert Hailey -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071212/a6612ca8/attachment.html>
