[tor-bugs] #25687 [Core Tor/Tor]: extreme over-report of observed / self-measure bandwidth on fast hardware -- critical to torflow / peerflow

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Apr 2 01:52:30 UTC 2018


#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


More information about the tor-bugs mailing list