I'm back to complain further about erratic bandwidth authority behavior, previously
[tor-relays] BWauth kookiness https://lists.torproject.org/pipermail/tor-relays/2015-May/007039.html
Allowing that BWauths are in a bit of flux, with tor26 replaced by maatuska and moria1 dropping the GuardFraction calculation, the bandwidth calculations evidence wildly erratic swings.
Specifically my relay, which is perfectly stable, reliable, fast (9.375 Mbyte/sec) has been assigned a jaggedly random series of consensus weights.
https://atlas.torproject.org/#details/4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1...
earlier, fairly sane
*gabelmoo Bandwidth=7701 Measured=9960 tor26 Bandwidth=7701 Measured=9340 moria1 Bandwidth=7701 Measured=18000 GuardFraction=66 longclaw Bandwidth=7701 Measured=12800
later, bit high, nutty
gablemoo Bandwidth=9375 Measured=17100 moria1 Bandwidth=9375 Measured=77900 GuardFraction=75 *longclaw Bandwidth=9375 Measured=23000
now, sane but undervalued
gablemoo Bandwidth=8925 Measured=14900 maatuska Bandwidth=8925 Measured=17200 moria1 Bandwidth=8925 Measured=5330 *longclaw Bandwidth=8925 Measured=7440
moria1 here is downright schizophrenic but other BWauths regularly double and halve the bandwidth value they assign. Graph shows it a more vividly.
What the graphs and numbers do not show is that the effective difference between the consensus values of ~7000 and ~23000 is staggering. At the low end of this range the relay shows roughly 2500 active circuits and a average load factor of about 20% of actual bandwidth, while an assignment of 23000 results in almost 8000 circuits and a load factor of more like 50% (both per Blutemagie.de).
My point is that BWauths should not be arbitrarily flipping stable, well run relays from the top to the bottom of this steeply sloped sweet-spot of the weighting curve. Perhaps the sweet-spot range has moved over the last couple of years as the price of bandwidth has dropped and faster connections become more prevalent, and this has been overlooked in the algorithm.
Regardless, it seems BWauth measurement should be more nuanced in this particular range, such that relays are not slammed constantly between "rather popular" and a "bit boring" irrespective of their actual available capacity.
One reason this vexes is that I would like to see how well the relay runs with Address Sanitizer active. ASAN provides obvious benefits w/r/t security, but entails a performance trade-off. With the BWauths throwing darts, eyes closed, when choosing weighting, it's impossible to gauge the performance impact of various adjustments.
In the bigger picture view, erratic BWauth weighting can't be adding clarity to the performance, capacity and utilization situation.