<snip>
<snip>Martin Stone Davis wrote:
The solution is to look ahead in our list until we find a nice query/node combination. This could be done by sampling a certain number of queries from the ticker randomly. Then, for each one sampled, and for each node in the RT, calculate estimate(). Pick the *combination* with the smallest value.
What you are suggesting will result in fast queries getting faster, and slow queries timing out - but producing considerable CPU load in the process. Is this a good thing?
It is the case in general that fast queries will get faster, but it's not as simple as that. With QR backoff, the set of keys which are "fastest" will change over time as our RT nodes go in and out of availability. In any case, I don't see anything wrong with accentuating the positive and eliminating the negative.
As for the CPU load, read the follow-up I wrote to the original plan:
Better: fix the number of query/node combinations that we plan to look at. Stop sampling queries when we surpass that number. E.g. we might pick that number to be, say, 300. Then, if 30 nodes are backed off and 20 are available, we would sample 300/20=15 queries.
So we can control the CPU load. We can always experiment with what fixed number of query/node combos is best in terms of: 1. improving routing, while 2. not exploding CPU usage.
Isn't this idea worth trying?
-Martin
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
