Let's take Jonathan's example: >Node 1 - pSuccess 0.1 tSuccess 1000 pFailure 0.9 tFailure 2000 >estimate = 1900 > >Node 2 - pSuccess 0.9 tSuccess 5000 pFailure 0.1 tFailure 10000 >estimate = 5500
For node 1, nSuccess/t = 1/(1000+0.9*2000/0.1) = 1/19000 For node 2, nSuccess/t = 1/(5000+0.1*10000/0.9) = 1/6111
So, node 2 really is better than node 1 since it returns more data per unit of time.
Interesting, but the issue is that the tFailure used in the current NGR algorithm is not the time required to receive the failure, tFailure is the time required to receive the failure PLUS THE ESTIMATED TIME TO REREQUEST THE DATA FROM SOMEWHERE ELSE AND GET IT. Lets call that globalTReceive.
In Jonathan's example lets say that globalTRetrieve is 4000, the current estimates would actually be:
Node 1; (0.1*1000) + (0.9*(2000+3000)) = 4500 (0.9*5000) + (0.1*(10000+3000)) = 5800
Note that this reduces the difference between our estimates for the node, but Node 1 still wins since the benefit of the fast response, even though it is unlikely, still outweighs the cost of it failing forcing us to get it elsewhere.
I still don't have my head around this fully yet, but I think the core flaw in your proposal is that it assumes that, for a given key, the pSuccess values of repeated requests to the same node are independent, but they are not. After the first failure, pSuccess for that node drops to 0.
Whatever the algorithm, it MUST consider the cost of re-requesting the key elsewhere in one way or another - since a lower global average re-request time is likely to make a sensible algorithm more willing to try an unreliable but fast node, but so far as I can understand - your algorithm does not consider this.
Ian.
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
