#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: Component: Core Tor/Tor | Version: Tor: 0.3.3.3-alpha Severity: Normal | Keywords: Actual Points: | Parent ID: Points: | Reviewer: Sponsor: | ------------------------------+-------------------------------- Have observed that on fast hardware the maximum bandwidth estimate reported by `rep_hist_bandwidth_assess()` and published via `ri->bandwidthcapacity` is frequently overstated and have seen it go as high 160% of true physical bandwidth, stay there for days.
Connected today in my mind that this may be one of the larger causes of `torflow` misbehavior No control system will function correctly with bad input data and without question +60% qualifies as bad--GIGO. Problem appears to have worsened with the arrival of KIST scheduler. Have no idea why it occurs, but have see for years, with overrating appearing relative to absolute physical link speeds and relative to Linux `tc-police` rate limits. Even `peerflow` when it arrives will require reliable measurement data to function properly. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25687> 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