On Friday 29 October 2010 17:24:30 Robert Hailey wrote: > > On 2010/10/29 (Oct), at 6:22 AM, GitHub wrote: > > > From: toad > > > > This will not be merged, period. > > It needs a little more work anyway :) > > > We do not make significant changes to routing without detailed > > simulations. The Least Recently Used policy used for opennet has > > been extensively simulated and while it is not proven, there is also > > a very strong mathematical basis for it. There is every reason to > > think that it should perform well, in other words, and automatically > > establish a small world topology. Plus, it trades off performance > > against location in a way which is simple and avoids any need for > > extra layers of performance evaluation separate to optimising > > locations. > > You might be right if LRU was the only factor. However, I think that > the announcement algorithm accounts for 95% of peer selection. > > In my experience, nodes announce... get peers at the given location... > and then are forevermore content with the announce-gathered peers. LRU > would only have the effect that you state if we routinely dropped the > lowest peer (in such a way that they could not just reconnect). > > > Finally, I don't believe routing is the problem limiting performance > > on the current network. The distribution of incoming requests is > > usually very specialised, for example. > > Incoming requests are specialized, that's true! But this indicates > that *those requests that get to us* are specialized. The overall CHK > success rate is a better measure of network health IMO.
And it's amazingly good by historical standards if you look at the higher HTL numbers. IMHO the rapid decline below 16 is to be expected because a lot of stuff is answered quickly. However, IMHO there are lots of possible problems that would cause poor performance by that measure other than poor routing. And they do. Data persistence in particular is relatively poor. And I believe this is caused by poor load management - inserts rejected by the nodes where the data should be stored, etc. > > It's too bad that there is not a way to experiment on the whole > network without negatively effecting it; e.g. it would be *very* bad > if a routing change prevented update-over-freenet. I guess we could > run two parallell networks, but would require reduplicating much code. Update Over Mandatory means auto-update will work in *almost* all cases unless we *really* mess things up in e.g. the transport layer or announcement. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20101030/eace914f/attachment.pgp>
