On Sun, Sep 21, 2003 at 10:39:40PM +0200, Benny Amorsen wrote: > 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
I doubt it. Query rejection is about the lightest operation we can do involving sending a message. It does not cause a connection to be opened, for example, even if all conns are blocked. Routing the query would involve a full blown routing, and would ALSO involve sending a DataRequest out - a larger message than the QueryRejected, which will cause a connection open if necessary. > 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. Yes, there is a problem with load balancing. > > 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 It is about as cheap as it is going to get. The latter: NGRouting *should* do this to the extent that it is needed and no more. Anything more would be the alchemy we all know and hate from CPAlgoRoutingTable. > 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. How expensive? > > 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. The former would severely slow down most requests. The latter - have you any ideas? > > Oh by the way, RoutingTime is a pretty bad estimator of CPU load. But > that problem is insignificant next to the others. messageSendTime is a better one in practice, but it depends on other factors. But we COULD use that instead. > > > /Benny -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
