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
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
