On Friday 26 Jul 2013 17:47:29 Robert Hailey wrote: > > First, is it safe to frame the freenet performance issue as: "the rate you > get for any particular request is the rate of the slowest/most-congested node > in the request chain"? > > I ask b/c I seem to recall a target time for streaming CHKs, or something... > so the fundamental assumption might be wrong. > > But if it's not an invalid assumption, I had an idea which might boost > performance all-around, but might also effect routing (so it's here for > discussion). > > Basically, it's quite easy to determine what the "average bandwidth" of our > peers is, as seen here: > https://github.com/Osndok/fred-staging/commit/698591a15061df5896400e46e3439097e92287d5 > > ...which also defines a function to test if a peer is "above average", maybe > letting us try the "fast lane" first (if the request came in on the "fast > lane") to try and avoid a slow-down, sorta like: > > PeerManager::closerPeer(...) > { > Set<PeerNode> available; > > available=new ArrayList(connectedPeers()); > available.removeAll(routedPeers); > > if (available.isEmpty()) > return null; > > Set<PeerNode> temp; > > if (originatingPeer.isAboveAverage()) > { > temp=pickOutAboveAveragePeersFrom(available); > if (!temp.isEmpty()) available=temp; > } > > //... > > temp=pickOutPeersThatAreNotBackedOff(available); > if (!temp.isEmpty()) available=temp; > > return closestPeerInSet(available, location); > } > > I imagine that the most routing-disruptive case to consider is with 4 peers & > 2 above average; b/c you need at least 2 above for the code to do anything > (receive from above average, route to above average). > > Thoughts? > > BTW, closerPeer is not written in the above format, but shouldn't it be? It > seems overly complicated, but if it's optimized for runtime speed (or memory > churning, or something in particular) I wouldn't want to step on anyone's > toes by wildly refactoring it.
You've just reinvented NGRouting. :) This sort of thing is possible in principle - there's been some theoretical work on it - but making it work well without seriously upsetting routing and without getting a massively over-centralised topology is difficult. Also the speed of a single request isn't that important anyway; what determines performance is really how many we run at once. And other things like how many hops they take, whether they find the data at all and so on.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
