On November 07, 2003 06:27 pm, Toad wrote: > One radical solution: > Remove the code to reject queries when the bandwidth limit is exceeded! > > NGRouting can figure out when nodes are slow due to long term overload a > lot more easily and less alchemically than it can deal with query > rejections. Or so the theory goes. Am I smoking crack here?
Maybe not. This is worth a try. > On Fri, Nov 07, 2003 at 11:13:14PM +0000, Toad wrote: > > Currently the situation, even with the recently integrated probabilistic > > rejection, is as follows: > > We start off with no load > > We accept some queries > > Eventually we use up our outbound bandwidth, and due to either > > messageSendTimeRequest or the output bandwidth limit, we reject queries > > until our currently transferring requests have been fulfilled. > > With our current running average code, at this point the node's > > pSearchFailed estimate will go through the floor, and it won't recover > > because it won't be routed to. > > Possible solutions proposed: > > 1. Try the nodes again after some fixed, perhaps increasing, backoff, > > once we are into QR mode. One way to do this is to abuse the > > pSearchFailed estimator as edt has suggested; another way would be to This leads to the SearchFailedCount dropping from 4-6 to 1-3. > > randomly fork requests occasionally such that each node in the RT is > > visited at least every N seconds as long as the node has some load. > > The search failed estimator will recover quite fast if it gets retried > > and is not queryrejecting. > > 2. Use a really long term average. I have tried this. It leads to SearchFailedCounts of 6-10. It would seem that reacting fast is _good_. > > 3. Have the node somehow guess when it will next be available for > > queries, and tell the requesting node, which then uses that as a backoff > > time. Somebody suggested this too essentially. You could perhaps > > guesstimate it from the transfer rate... but sadly the transfer rate > > will vary over time.. Having the node guess when It will be ready would be fine IF we can get a good estimate - this this will be tricky to do. As you say it depends on many factors. Suggest that we comment out the code that causes QR on bandwidth limits and test. If that does not work then try my idea. Ed Tomlinson (edt) _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
