On October 02, 2003 07:47 pm, Martin Stone Davis wrote: > Ian Clarke wrote: > > 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. > > Hand-wavy explanation: When trying to ask "how long will it take this > one node to give us a 1 unit of data?" we don't have to be concerned > about how our opinions about pSuccess will change in the future. All > that matters is the true value itself. Since we don't know the true > value, the best we can do is use our current opinion of the true value. > > Admission of guilt: As I wrote it, pSuccess is a bit ambiguous: is it > the current (and changing) estimate of how likely future successes will > be? or is it the "true" (and static) chance of success? If the former, > then we'd write it with a little hat on top. If the latter, we'd > probably use a greek symbol for it. Since I didn't do a very > mathematically sound derivation, it would be problematic to discuss your > concern here in detail.
pSuccess is a function of (node,key). It will vary for a give node depending on the key passed. This is what worries Ian about your suggestions. Also we do not just use tFailure. The term is (tFailure+tToDoThisOnAnotherNode(key)) Ed > Changing the subject: Let's hold off on that until I address the more > troubling problem you raise below and I also come up with a more clear > derivation. > > > 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. > > I see your point. The choice is not between the tortoise and the hare. > There are many tortoises and many hares! Suppose there are only 2 > nodes to choose from. Then, we have at least two choices: try node 1 > first, and failing that, try node 2 OR try node 2 first, and failing > that, try node 1. With 3 nodes there are at least 6 choices. With n > nodes, there are at least n! choices. I say "at least" because there > are even more strategies to choose from: e.g. try node 1, and failing > that, try node 1 again, and failing that, try node 2. > > So the trick is coming up with a strategy that minimizes the total > expected time to achieve a successful result. I'll try to work that out > on paper and get back to you when I have something. > > -Martin > > > _______________________________________________ > Devl mailing list > [EMAIL PROTECTED] > http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
