over-report of observed / self-measure bandwidth on fast hardware -- important to torflow / peerflow
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.