#25687: extreme over-report of observed / self-measure bandwidth on fast hardware -- critical to torflow / peerflow --------------------------+------------------------------------ Reporter: starlight | Owner: (none) Type: defect | Status: new Priority: Medium | Milestone: Tor: unspecified Component: Core Tor/Tor | Version: Tor: 0.3.3.3-alpha Severity: Normal | Resolution: Keywords: | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: --------------------------+------------------------------------ Changes (by starlight):
* version: => Tor: 0.3.3.3-alpha Comment: In my view the problem constitutes a critical measurement error. The most important consumer of this value is `torflow` and overstating true available bandwidth distorts consensus allocations. No chance overstatements are correct, especially in the traffic-control scenario where Linux caps bandwidth with fine-grained, reliable precision. Some ISPs permit traffic to burst briefly before enforcing bandwidth restrictions, but in the cases I've seen bandwidth self-measure is well in excess of the the line burst rate and anyway reporting burst-rate maximum capacity to torflow is counterproductive. The impact of the issue may be acute due to torflow's control-signal reliance on measurements of marginal unused bandwidth rather than actual capacity. To venture a guess, any of queuing (as suggested), chunky event-loop processing delays, course time precision, misalignment of time determination vs. data accounting are likely culprits. Setting milestone was unintended, was thinking of the latest reproducing version. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25687#comment:3> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs