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@xxxxxxxxxxxxxx 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
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays