[tor-relays] BWauth no-consensus state in effect

s7r s7r at sky-ip.org
Tue Aug 4 22:50:28 UTC 2015

Hash: SHA256


That is correct Mike Perry - (at least in my case) Tor is much slower
(any page takes more time to load) than when bandwidth authorities
were assigning weights. This happens on 2 different client computers
and one live Tails (obviously each uses a different Guard). I wouldn't
say it is now slow enough that someone wouldn't be using it, but it is
indeed slower than it was before (pre-self advertised weights).

I don't think it's a good idea to get back to self advertised weights.

On 8/5/2015 1:17 AM, Mike Perry wrote:
> Roger Dingledine:
>> On Thu, Jul 30, 2015 at 08:53:33PM +0200, nusenu wrote:
>>> Has this fallback happened before (=some experience on the
>>> potential impact available) or is this outage happening for the
>>> first time since the bwauths are in place?
>> Indeed, it happened a few times back in 2010-2011 when we were 
>> first rolling out the bwauths: 
>> https://metrics.torproject.org/torperf.html?graph=torperf&start=2009-05-06&end=2015-08-04&source=all&filesize=50kb
but it's been mighty stable since then.
>> Interestingly, you'd expect a big bump in torperf response times 
>> when we switched to self-advertised weights. But there isn't
>> one: 
>> https://metrics.torproject.org/torperf.html?graph=torperf&start=2015-07-06&end=2015-08-04&source=all&filesize=50kb
> Some years ago, Karsten made a nice overlay of bw auth failures to 
> torperf data, which allowed us to see a 4-5X reduction in torperf
> fetch times while the bw auths were active vs not.
> I just added a comment to 
> https://trac.torproject.org/projects/tor/ticket/16696#comment:3
> asking Karsten to repeat this visualization. That might be a bad
> place to do it, though. Might need a new ticket (or tickets)?
>> I'm guessing this is because we have enough relays, with enough
>> capacity, to handle the current load adequately.
> I'm wondering if the downtime in this case hasn't happened for a
> long enough stretch of consecutive consensus periods for it to
> impact the network. That might be one explanation. Spare capacity
> might be another.
>> But that doesn't mean the current relays are useless.
>> Historically speaking, it means pretty soon more users will show
>> up, once word gets out that Tor isn't as slow as it used to be.
>> :)
> I worry that the "capacity economics" involved here might not have
> the same properties as they used to, and that we might not see
> increased adoption as a result.
> In particular, the switch to one guard makes it much more likely
> that a new user will pick a slow guard and this will cause them to
> have a horrible Tor experience.  With three guards, you had a much
> better chance to get at least one fast guard in that case, and then
> CBT could sort out which was which.
> In my case, I usually pick my guards manually for ease of use with
> my firewall, and as a result performance is always very fast with
> the three fast guards I have chosen (I often get throughput
> 750k-1MB/sec for large transfers). In some instances where I have
> not selected my guards manually, Tor Browser is unbearably slow.
> Like really, really painfully slow. The whole time. Until I
> reinstall it.
> This makes me think that the performance of people who pick guards
> from the tail is much much worse than the performance of the top
> guards, and this property likely is acting as a deterrent to
> adoption. If even a small fraction of users perceive Tor as totally
> unusable, the word of mouth is still going to be "OMG Tor is like
> So long as this keeps happening, I suspect it is unlikely for
> people to rush to Tor because it is now faster.
> I think once we expect most of the clients to have switched to 1
> guard, we should get some torperf graphs going for guards of
> various capacities, and see what the actual effects of this are.
Version: GnuPG v2.0.22 (MingW32)


More information about the tor-relays mailing list