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.
absolutely! Hopefully we agree that minimizing the percent of bandwidth spent on QR's is a desirable goal. It appears that my outbound bandwidth is divided "about" 65/35 trailers:QRs, and that's not a good thing. But it's comforting to have a sense of the "waste" , because any QR is a waste of network bytes. It does provide a little bit of info (that I'm busy) to the requestor. It certainly isn't an efficient way to inform though. My concern is the manner in which my node accepts/rejects. For 10 minutes, the window is closed. Then for 48 seconds, the window is wide open, and all requests are accepted. Then the window slams shut again. What this would mean for most peers, IF they queried at a constant rate, is that only 1 of 10 get through to me, and they must pick a different route most of the time. Yet for some reason they chose to route to me (first? i dunno!).
If 80% of queries are being rejected, globally, this implies that there are 'too many' requests being made, and _we_are_ _attempting_to_throttle_them_ , albeit passively by a receiver, rather than a sender. Long-term - what if sender and receiver could 'tune' an optimal rate ? Ian very recently suggested a backoff deal, like "squelch the next 5" or something similar.
and Martin Stone Davis wrote: > From servlet/nodestatus/diagnostics/outputBytesLow/minute: > From servlet/nodestatus/diagnostics/outputBytes/minute:
ahhh, another peek into what's going on! Here's what I saw... outputBytesLow/hour = 17348859 (the last 10 were within 10%) outputBytes/hour = 21609829 (these are also quite steady)
however, linux 2.4.21 sent out about 33.5MB total in this time. Nothing else was running, and my firewall drops most everything coming in that could produce a response, other than Freenet. So trailers are getting somewhere between 50% and 80% .
Thank you both for educating me! Now I know a little more - and I can better complain ;)
BTW Neither of you answered the original question - what are your rejection rates ? I'm not convinced that they just don't matter.
> node:s status :) And... some of those outputBytes that isn't prio 'Low' > might be data too.. I think it works something like: when a trailer has > waited long enough it will be escalated to a higher prio..
(noted - I chose to ignore this for now)
Ken
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
