[tor-relays] BWAUTH weightings too volatile. . ."twitchy"

[starlight.2015q2 at binnacle.cx]

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/4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2

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.