why not take a gander at -This is why you are QR:ing most of the time. You are sending lots of data to other nodes. That's not necessarily a bad thing, in fact, it might be very good. The real question is: how much of your outgoing bw is used up by QR:s, how much is used by routing requests, and how much is used up by "real" data. I wish I knew how to tell this.
http://localhost:8888/servlet/nodestatus/diagnostics/localQueryTraffic/day
and share with the free(thinking) world how you're doing... (just a one liner 'good' 'bad' '98.2% rejected' etc)
fred says I REJECTED 94% of almost 1.000.000 requests yesterday (while running 5030, then 5031). Wow, that really sucks. I haven't determined what percent of my bandwidth is being wasted by this.
I have seen evidence that _my_ original requests are flogging MOST of my peers in the routing table with one single request, as one by one they reject the request. Now, if many people are observing this, it may be time to abuse the maxRoutingSteps setting in freenet.conf/ini, by lowering it to 10. I am NOT recommending anyone do this, I'm just submitting it for the experts to weigh in on. To be used just for the short-term, while this problem is brought under control. It would need to be applied widely to have much effect, so maybe no help here. It looks inappropriate for a single request (HTL=20) to visit 100-800 nodes, just to be rejected (5 to 40 attempts at each hop) before it terminates. It is difficult to believe that I'm "contributing" to Freenet by running a node when I see this going on.
The "General Info" page reports: Current routingTime 1ms Curent messageSendTimeRequest 161ms Pooled threads running jobs 73 (60.8%) Pooled threads which are idle 46 Current upstream bandwidth usage 6194 bytes/second (88.5%)
If the amount used up by "real" data is pretty high, and the QR:s aren't using up a bunch of CPU then there's no cause for alarm.
Reason for QueryRejecting requests: Estimated load (100%) > overloadLow (85%)
Current estimated load 100% [QueryRejecting all incoming requests!]
Reason for load: Load due to thread limit = 60.8%
Load due to routingTime = 70% = 85% + 15% * (1.636 - 1000.000) / 1000.000
Load due to messageSendTimeRequest = 80.8% = 85% + 15% * (161.643 - 1000.000) / 3000.000
Load due to output bandwidth limiting = 100% because outputBytes(371641) > limit (336000.005 ) = outLimitCutoff (0.8) * outputBandwidthLimit (7000) * 60
now, looking at -
http://localhost:8888/servlet/nodestatus/diagnostics/localQueryTraffic/minute
is also distressing. Mine tells me that I flip-flop between accepting all requests, and then rejecting all requests. And I'm spending 97% of my time rejecting queries. For up to _30 minutes_ at a stretch. Does manyone else witness this pattern ? Ed Tomlinson said he has seen this for a long time. This (to me) implies it is probably widespread. IF the majority of nodes are demonstrating this oddity, shouldn't smoothing it out (reducing rejections) become priority #1 ??!
I understand why it *might* be helpful to have this smoothed out, but it isn't necessarily harmful.
How the current system might it be harmful?: If the repeated QR:s cause other nodes to quickly come to a much-worse-than-true estimate of pSearchFailed, then other nodes who happen to be querying us at that time will suddenly consider us to be terrible searchers; also, nodes who happen to query us during the time where we accept almost all will suddenly consider us to be great nodes and may then all flood us.
The big question is: is that actually happening or not? I can't tell.
I worry that frost might bring about Freenet's early demise, if that really is the culprit :(
here's my per minute report:
11/2/03 3:04:00 AM EST 1515 405 0.26732673267326734 11/2/03 3:05:00 AM EST 1214 0 0.0 11/2/03 3:06:00 AM EST 905 0 0.0 11/2/03 3:07:00 AM EST 539 0 0.0 11/2/03 3:08:00 AM EST 639 0 0.0 11/2/03 3:09:00 AM EST 615 0 0.0 11/2/03 3:10:00 AM EST 1401 0 0.0 11/2/03 3:11:00 AM EST 1013 0 0.0 11/2/03 3:12:00 AM EST 624 0 0.0 11/2/03 3:13:00 AM EST 524 0 0.0 11/2/03 3:14:00 AM EST 745 0 0.0 11/2/03 3:15:00 AM EST 1034 0 0.0 ( as you can see, 11/2/03 3:16:00 AM EST 599 0 0.0 I'm really not helping 11/2/03 3:17:00 AM EST 471 0 0.0 very much during this 11/2/03 3:18:00 AM EST 518 0 0.0 time ) 11/2/03 3:19:00 AM EST 776 0 0.0 11/2/03 3:20:00 AM EST 695 0 0.0 11/2/03 3:21:00 AM EST 539 0 0.0 11/2/03 3:22:00 AM EST 427 0 0.0 11/2/03 3:23:00 AM EST 875 0 0.0 11/2/03 3:24:00 AM EST 1170 0 0.0 11/2/03 3:25:00 AM EST 1188 0 0.0 11/2/03 3:26:00 AM EST 1194 0 0.0 11/2/03 3:27:00 AM EST 959 0 0.0 11/2/03 3:28:00 AM EST 908 0 0.0 11/2/03 3:29:00 AM EST 1224 299 0.24428104575163398 11/2/03 3:30:00 AM EST 950 644 0.6778947368421052 11/2/03 3:31:00 AM EST 803 0 0.0 11/2/03 3:32:00 AM EST 495 0 0.0 11/2/03 3:33:00 AM EST 456 0 0.0 11/2/03 3:34:00 AM EST 720 0 0.0 "query, query, 11/2/03 3:35:00 AM EST 706 0 0.0 go away. Come 11/2/03 3:36:00 AM EST 429 0 0.0 again another 11/2/03 3:37:00 AM EST 291 0 0.0 day" 11/2/03 3:38:00 AM EST 429 0 0.0 11/2/03 3:39:00 AM EST 627 0 0.0 11/2/03 3:40:00 AM EST 792 0 0.0 11/2/03 3:41:00 AM EST 471 0 0.0 11/2/03 3:42:00 AM EST 372 0 0.0 11/2/03 3:43:00 AM EST 471 0 0.0 11/2/03 3:44:00 AM EST 896 762 0.8504464285714286 11/2/03 3:45:00 AM EST 1174 9 0.007666098807495741 11/2/03 3:46:00 AM EST 807 0 0.0 11/2/03 3:47:00 AM EST 658 0 0.0 11/2/03 3:48:00 AM EST 911 0 0.0 11/2/03 3:49:00 AM EST 744 0 0.0 "I'm sittin' on the 11/2/03 3:50:00 AM EST 497 0 0.0 dock of the bay... 11/2/03 3:51:00 AM EST 700 0 0.0 watching the tide 11/2/03 3:52:00 AM EST 754 0 0.0 roll away" 11/2/03 3:53:00 AM EST 896 0 0.0 - otis redding 11/2/03 3:54:00 AM EST 703 0 0.0 11/2/03 3:55:00 AM EST 896 0 0.0 11/2/03 3:56:00 AM EST 617 0 0.0 11/2/03 3:57:00 AM EST 506 0 0.0 11/2/03 3:58:00 AM EST 1085 0 0.0 11/2/03 3:59:00 AM EST 743 0 0.0 11/2/03 4:00:00 AM EST 663 0 0.0 11/2/03 4:01:00 AM EST 551 0 0.0 11/2/03 4:02:00 AM EST 651 0 0.0 11/2/03 4:03:00 AM EST 693 0 0.0 11/2/03 4:04:00 AM EST 762 0 0.0
-Martin
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
