entries: 100 Global mean traffic (queries per hour):3321.9222222222224 Local mean traffic (queries per hour): 689.6485665846112 Current advertise probability: 0.15754031587654324 Current proportion of requests being accepted: 0.99
This is what I expect to see. I have out going bandwidth limited to half of the available, 6k/s. Node is well integrated with a 8G ds with about 19000 keys. I also have noticed the network has shifted my nodes specialization reciently. I was down for about 30 hours. After this my node was found quickly but after about three days I noticed the dense part of the routing histo had moved. Looking that the ds histo the content has not shifted much yet. Nodes changing specialization after a short down my also be part of the problem... Ed Tomlinson On May 16, 2003 03:42 pm, Toad wrote: > On Fri, May 16, 2003 at 07:29:02PM +0100, Toad wrote: > > Or alternatively, > > > > http://127.0.0.1:8888/servlet/nodestatus/version_histogram.txt > > > > :))) > > > > > > (My apologies for the *horrible* perl -- it's not my best language.) > > > Anyway, this shows that out of the 100 nodes in my routing table, only > > > 14 of them are running pre-build-579 nodes. Builds 593-595 dominate > > > in this part of Freenetland. (That one build-629 node is probably > > > pre-pcaching too, but I'm not certain.) > > > > > > > Maybe we should make 0.5.2 mandatory? > > > > > > I think there's not enough evidence on either side of the pcaching > > > argument to decide this yet. > > > > There won't be until pcaching actually does something. The statistics > > strongly suggest that pcaching is not doing much because every two hops > > or so it hits a pre-pcaching node. Or that there is some extremely wierd > > bug happening somewhere... > > So, a theory presents itself: we have > Set A: N nodes with high traffic, ~3k reqs per hour to ~ 100k reqs per hour > Set B: M nodes with low traffic, hundreds of reqs per hour or less > > N is a LOT smaller than M. > > Set A nodes have low advertising (datasource reset) probabilities, but > Set B nodes have high advertising probabilities, due to the load > balancing algorithm, which evidently isn't working. Hence a request > goes out on the network and after a few hops meets a set B node, and > gets its datasource reset and consequentially hopsSinceReset set to > zero. Interestingly, the nodes that get little traffic are NOT locally > overloaded, or they would have lower reset probabilities due to the > (proportion of requests accepted) ^ 5 which is multiplied into the reset > probability... > > Any suggestions as to what to do about this? > > BTW, I want to see some reset probabilities from live nodes to try to > confirm this statistically. Mail me the top five lines from > http://127.0.0.1:8888/servlet/nodeinfo/networking/loadstats > > > > -- > > > Greg Wooledge | "Truth belongs to everybody." > > > greg at wooledge.org | - The Red Hot Chili Peppers > > > http://wooledge.org/~greg/ | > > _______________________________________________ > devl mailing list > devl at freenetproject.org > http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
