-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi,
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 > SOOOOO UNUSABLY SLOW!!" > > 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. > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJVwUG0AAoJEIN/pSyBJlsRyUcH/jOkx+8YxBQMCAJyyHWtl6WJ Ix8ItcJOkMry8Mt0pGrmlgwYQjmoP/jv9RzFMVNc60rKpSjFHxUk0YAyZfXB4Zhj sX/ZfBdhcQv6hZZ431Iqp/D/GOdAVOGlk8XnKczddPXQc5kO+OY4pQKYV6Eotn2v fOTuwy0pst5pcDvH/6ZTa52mN+DBrOTqlL7JY4Hx8BdWds2FpMvYWdP/Jk+GbE5m /1QkfgRjox8sMnn+y+nbaswGjQ4y2EWjVSXU/TbJyam3XJHR1WDwrlYQma86JUGZ Yu/u6VAyG6+JCk72bMD+ofO5yQmeo3ii2WhYTcF5H60N91p/6mKkPxOcm4Xr418= =t/IX -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
