Hi,
Thanks for reporting this issue, and sorry it's taken us a while to get back to you. Many of us have been on leave over the holidays, and we're still catching up.
On 4 Jan 2020, at 10:18, trusting.mcnulty@protonmail.com wrote:
An update on my relay 'kima' ($54A35E582F9E178542ECCFA48DBE14F401729969) --
Eventually I did get assigned more weight; the relay is currently at 4600.
Along the way I think I discovered one potential problem with the bwauth bootstrapping process, at least for sbws. (I'm not sure about torflow.)
Torflow's partitions have a similar issue, but it's actually worse: a relay can get stuck in a low-bandwidth partition forever.
When sbws is constructing a two-hop measurement circuit to run a test, it tries to pick an exit that has at least twice the consensus weight of the current relay-under-test: https://github.com/torproject/sbws/blob/master/sbws/core/scanner.py#L216
So this means that in this case, sbws would have picked any exit that was not a BadExit, has an acceptable ExitPolicy, and has a consensus weight of at least, well, 2. That's not a lot.
As it turns out, something like 10% of exits have under a 600Kbyte/sec advertised bandwidth. So it seems pretty easy from this weight=1 bootstrap scenario to get paired with an exit that will give poor test results.
Perhaps bwauth path selection should also choose a testing pair from exits/relays with a certain absolute minimum of weight or advertised bandwidth?
I've opened a ticket for this issue: https://trac.torproject.org/projects/tor/ticket/33009
We'll try to resolve it before we deploy any more sbws instances.
T