On Sat, Nov 08, 2003 at 07:33:47AM -0500, Ed Tomlinson wrote: > 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.
On one node. If it is widely deployed it may not be so effective. > > > > 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) > -- 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
