On Tuesday 22 January 2002 17:16, you wrote: > On Tue, Jan 22, 2002 at 10:13:48PM +0100, Oskar Sandberg wrote: > > On Tue, Jan 22, 2002 at 02:52:39PM -0500, Tavin Cole wrote: > > > On Tue, Jan 22, 2002 at 06:58:51PM +0100, Oskar Sandberg wrote: > > > > < > > > > > > > I agree with thelema here - clearly the routing table is adaptive > > > > already, there is no need to make the CP include all reasons to avoid > > > > a node. Specifically, the CP is good for temporary errors that can be > > > > recovered from suddenly, while an overloaded node (for example) > > > > indicates a constant problem. It's not binary. The CP is the parameter that lets the connection management algorithm learn, "I can push 3 requests a minute at this ref, but I can't push 30".
> > > > > > The way Gianni has done the routing table, CP is really being used to > > > store long-term information about the node, while the other factors > > > (failure intervals, failures per interval, interval timeouts, masking > > > effects) are used to deal with temporary network errors. CP stores information like "is thelemas node usually busy". Backoffs store information like "was I able to contact thelema's node 10 minutes ago". > > > > Then the CP ought to go. Here we go again... > > I tend to agree. I don't think it really does anything in the current > system. > > When I first put in the new routing table code, I was experimenting with > a simpler CP system. There were 3 parameters: CP, failure count, and > last attempted time. Whever there was a connection failure, the CP was > set to zero and the failure count was incremented. The effective CP > value used in the routing decision was: > > CPeffective = CP + k * (current time - last attempted time) / (1 + > failures) > > This should cause nodes to be retried after a while (basically achieving > the same "masking" effects as the current system), and has a balancing > effect: if a node is 10x as likely to be picked in routing based on > reference domination, then its effective CP after a failure would be > 1/10th of nominal, but since it will be attempted 10x as often, the > "backoff time" should be about the same for any node regardless of its > dominance in refs. > > When there was a successful route, the CP was increased by .2 and the > failure count was cut in half. I also thought about adding an > exponential damping when the failure count grew very large. > > This code is semi-defunct and still lingering in > freenet.node.rt.Probability and freenet.node.rt.ProbabilityRoutingTable. > > -tc > Tavin, Oskar: I am really tired of arguing over the CP issue. Here are some observations: 0) The current system works. 1) Now that we have moved rate limiting into the Application layer, nodes respond much more often and aggressive connection management is less important. 2) Tavin's code would also eventually work. It will most likely require some tuning to make it really work. 3) It does not appear to me that Fred is so well debugged that the legions of idle Freenet developpers have nothing better to do with their time than to rewrite working code. Does anyone care whether Freenet ever actually works? Or will it always be 2 weeks away? --gj _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
