On June 29, 2003 05:51 pm, you wrote: > Ok, we need to think about how to account for DNFs in NGrouting - and we > want to do it with the minimum of alchemy. > > The problem is that most DNFs will be "legitimate", meaning that the > data wasn't in Freenet so the node shouldn't be punished for returning a > DNF. But how do we know which DNFs are and are not legitimate? > > The answer is, we can't - but what we can do is look at a node's DNF > performance over time, and observe whether it is returning DNFs more > frequently than the best-performing node in our routing table. > > Why the best performing node? Well, we want to estimate the ratio of > requests for which there is actually data in the network. Imagine an > ubernode - one which is extremely smart and incredibly effective at > finding what it is looking for (therefore not DNFing). Well, no matter > how smart it is - it isn't going to be able to find data that isn't in > the network - so its DNF ratio is likely to be a good indicator of the > ratio of requests for which data exists at all. > > So, now we know that a node is performing less effectively than the best > performing node, how should it be penalized when calculating estimated > routing time? This is a tough one, since it demands that we quantify > the time-cost of a node failing to find some information which actually > exists. Ultimately this is impossible to do - but we can take a stab at > it by pretending that all requests are part of a splitfile download. In > this case, the cost of a failed request is the cost of having to request > another chunk of data to replace the one we didn't get. Now, clearly > this doesn't account for the mental anguish someone might have if they > don't get their daily dose of TFE - but at least it has some realistic > basis in reality. > > So, to account for the liklihood of unwarrented DNFs - we should add the > following to our estimate: > > timeEstimate += (bestDnfProb) * thisNodeDNFResponseTime * HTL + > (thisNodesDnfProb - bestDnfProb)*globalAverageResponseTime > > Note, the thisNodeDNFResponseTime is normalized by HTL which is why we > must multiply the HTL of this request back in. > > Reasonable (at least as a first iteration)?
Thinking about it this worth trying. Using: P_success(node)*success_estimate(key,node)+(1-P_success(node))*dnf_time(node)+global_success_estimate(key) sends lots of messages to fast nodes that get lots of DNFs. I will try: P_best_dnf() the node with the lowest dnf ratio. On my current system this would now we .52 then P_best_dnf()*dnf_time(node,key)*htl+(P_dnf(node)-P_best_dnf())*global_success_estimate(key) I will also look at putting a switch that allows ng to be turned on and off. Ed _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
