On December 02, 2003 05:44 pm, Ed Tomlinson wrote: > On December 02, 2003 04:59 pm, Toad wrote: > > On Tue, Dec 02, 2003 at 04:56:41PM -0500, Ed Tomlinson wrote: > > > Hi > > > > > > How about this. > > > > > > We keep one number: long estimateLimit; > > > > > > We accept a request if the best estimate in the routing object better > > > than the limit. > > > > > > If the load is higher than our HighLoadLimit we decrease estimateLimit > > > and if its lower than our LoadLoadLimit we increace estimateLimit (say > > > using .95 and 1.05 to start with). > > > > More lovely alchemy. But the main concern is as Ian's load balancing > > scheme - how do you prevent the estimateLimit from getting really high > > or really low and taking ages to recover. > > Yes, but on the other hand it requires no queue and adds no latency... > estimateLimit will quickly adjust as it will be calculated for each request > and had direct damping feedback from the node load - Ian's load balancing > scheme depends on another node responding for its feedback loop and so can > easily get out of control.
As an alternative, if we consider there is a direct relationship between load and estimateLimit, then (load-oldload)*k (where k is a damping factor chosen alchemlic) can be used to adjust estimatedLimit. Suspect this would converge faster, if it is required at all. Also note this request if very similar to the one proposed by toast. In this case, in effect, we use a running average. Toast suggestion uses a median. Ed > > > > This way we accept requests that have good estimates and vary what we > > > consider a good estimate depending on the load. > > > > > > Note that this could also be applied to CP routing replacing > > > estimateLimit with CPLimit. > > > > > > Comments, > > > Ed > > > PS. I can implement the above quickly if we agree its the way to go. > > > > > > On December 02, 2003 03:23 pm, Toad wrote: > > > > Here is how I propose to implement selective accept on NGR: > > > > > > > > We keep two numbers: > > > > int totalRequestsAccepted > > > > double totalRequestsConsideredTimesLoad > > > > > > > > We have the function targetAcceptRatio(), which tells us what > > > > proportion of requests we want to accept, based on the current > > > > estimated load (if anyone has a non-alchemical way to do this...) - > > > > one possibility is that it is 1-load, another is that we accept > > > > everything up to some value (say overloadLow) and reject everything > > > > above some value (overloadHigh), and increase linearly in between. > > > > Because of the hoped for effects, I am not sure that the first option > > > > isn't the better one. > > > > > > > > When we get a request: > > > > totalRequestsConsideredTimesLoad += targetAcceptRatio() > > > > If totalRequestsAccepted > totalRequestsConsideredTimesLoad , > > > > we know that we have accepted too many, so reject. > > > > Otherwise, accept, and totalRequestsAccepted++. > > > > > > > > Thus, we don't need to queue requests, there is no additional > > > > latency, and the implementation is really rather straightforward, > > > > apart from calculating the target acceptance ratio. And we accept the > > > > right fraction. We need to do some maintenance to maintain accuracy > > > > (subtract the largest whole part of both numbers from both numbers > > > > periodically), and we need one lock, but that's it. > > > > > > > > I will implement this on unstable soon, unless there are any > > > > objections. > > > > > > > > It requires NGRouting... > > > > > > _______________________________________________ > > > Devl mailing list > > > [EMAIL PROTECTED] > > > http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl > > _______________________________________________ > Devl mailing list > [EMAIL PROTECTED] > http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
