On 2003-09-21 at 21:40, Edward J. Huff wrote: > We are trying to keep bandwidth use constant and as high as > we are allowed, to keep thread usage down, and to keep > routing time down.
The problem is that while it is comparatively easy to control bandwidth usage and thread usage, routing time currently presents a very hard problem. The hypothesis is that query rejections lead to lower routing times. This should come from two factors: 1) It consumes less resources to reject a query than to handle it. 2) Rejecting queries leads other nodes to send fewer queries. Right now both of these seem to be false. Query rejection is a very heavy operation, and it just leads to the requesting node trying another node, which is probably just as overloaded. And from experience, even a constant 100% rejection rate will keep a fairly steady rate of requests coming for hours once a node has reached popularity. The solution, of course, is to fix it so that query rejection is a very cheap operation and so that nodes will back off /a lot/ when their queries are rejected. The work I did towards probabilistic rejection is possibly a step in the wrong direction, since it introduces expensive math into a fast path. On the other hand, the code it replaced was not exactly blazing fast either. Anyway, another reason that query rejections are expensive is that they result in a message being sent. This really should not be a heavy operation, but it seems to be. At least query rejections no longer cause new connections to be opened. One option would be to simply not send query rejections at all but just drop the request on the floor. Another option is to make messages less expensive. Oh by the way, RoutingTime is a pretty bad estimator of CPU load. But that problem is insignificant next to the others. /Benny _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
