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.