BWauth no-consensus state in effect
FYI list https://trac.torproject.org/projects/tor/ticket/16696 Description At present both 'longclaw' and 'maatuska' have dropped out of the BW consensus ('longclaw' is restarting with new version, not sure about 'maatuska'). This has caused the BW consensus logic to revert to using relay self-measurement for BW weightings due to fewer than three BW authorities participating. The 10000 cap placed on self-measure values is causing super-fast relays serious demotion and slower relays corresponding promotion in the consensus weighting. Possibly this may result in network unbalance issues. Some adjustment of the logic seems in order.
Thanks for the heads up! A fifth bwauth is expected to start voting "real soon now", and I'm not sure why maatuska didn't vote on bwauth data last vote, but I've pinged some folks so hopefully we can get this resolved quickly. -tom On 30 July 2015 at 12:04, <starlight.2015q2@binnacle.cx> wrote:
FYI list
https://trac.torproject.org/projects/tor/ticket/16696
Description
At present both 'longclaw' and 'maatuska' have dropped out of the BW consensus ('longclaw' is restarting with new version, not sure about 'maatuska').
This has caused the BW consensus logic to revert to using relay self-measurement for BW weightings due to fewer than three BW authorities participating.
The 10000 cap placed on self-measure values is causing super-fast relays serious demotion and slower relays corresponding promotion in the consensus weighting.
Possibly this may result in network unbalance issues. Some adjustment of the logic seems in order.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 30 July 2015 at 12:14, Tom Ritter <tom@ritter.vg> wrote:
Thanks for the heads up!
A fifth bwauth is expected to start voting "real soon now", and I'm not sure why maatuska didn't vote on bwauth data last vote, but I've pinged some folks so hopefully we can get this resolved quickly.
Aaaand we're back! =) Sorry for the outage. Bandwidth scanner status maatuska 6890 Measured values in w lines gabelmoo 6444 Measured values in w lines moria1 6754 Measured values in w lines -tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, starlight.2015q2@binnacle.cx:
thanks for this info. 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? -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVunKsAAoJEFv7XvVCELh0L5sQAKmyzbla8jXEhHjwwxFnu5k6 9Nxs7Rv1LUW9zUF3INRZQbXBBSYsxScyNi5b5hhZEVCoEqdjybqhgzZGdIadARxK 5vS/tAlf3sLMXyLVPHz+XIjnhdBZj/6RaOttDms+Ba0QpXvt9LhpIgkeZYM8ngmf EbU9ZyitMTH196X1SyPTtGhs0/ibB/ti7osWHauT6kDOBm3CtZo0hUIOGHPlPyas P0Tvikqn24q+2bh0zxFiCDTrAM4gmki840xZ0RLRMwFHDh08HZ98bufZDjHRIdyA iumBOnB43J26X2mDHRQlLidb++F99ppc8owLmMXQRjOM7ISk5B54fPEYRJvSe/A4 xP2a4bPJt3TV3ZnxAXnZ6HX7MOU55fo002LeWYqZJwQi6NQwz9PReivybYMlm+JV svMUttax3k4zHRwP3QUS6ChNdaXq1zPu9fEPuUpLnHL2xFruo+bNFu6+36wkk0tr g7N8VjDmuekI++IvLJEMnkoCtRDLx/sve7a1/1ovBJq3UdjstwbnqnbR5GgOXPAP kGMJ/RCblsxabrSONeoEc5P32zFLrDVcOClCx7UtjjJmzaD71p4vLxbJCrcJ4wh+ HYUPO0C+kEzGbUJrJC8CDEBoIfecw69PjDu7nJaxjJLKhjDbwuIrsFv4zu2Dg8ht zWvM99aluJWex9+jFsPz =p+Fb -----END PGP SIGNATURE-----
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&e... 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&e... I'm guessing this is because we have enough relays, with enough capacity, to handle the current load adequately. 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. :) --Roger
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&e... 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&e...
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. -- Mike Perry
-----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&e...
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&e...
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-----
Hi. I have to admit it is nice to see my relay getting some more serious use. It has seen a several fold increase in traffic over the last few days. On 08/04/2015 10:06 PM, Roger Dingledine wrote:
I'm guessing this is because we have enough relays, with enough capacity, to handle the current load adequately.
That is great to hear if it works out to be the case. More specifically to my relay, I know I have capacity that isn't being used. That said, it raises the partially-rhetorical question: should I spend my $x/month on running a relay or could that money be better used in other places? hope you are well tim -- Tim Sammut ~ @t1msammut ~ tim@teamsammut.com Ford-Mozilla Fellow at Amnesty International
On Wed, 5 Aug 2015 10:58:30 +0100 Tim Sammut <tim@teamsammut.com> wrote:
That said, it raises the partially-rhetorical question: should I spend my $x/month on running a relay or could that money be better used in other places?
Generally depends on if you are getting a good deal on bandwidth, i.e. how many terabytes per month for your $x. But I see you are running a relay in Costa Rica, where servers and bandwidth must be much more expensive than e.g. in Europe. I'm not sure how useful a relay in an exotic location, if it's expensive to run and pushes very little traffic. Maybe others can comment. BTW one way to increase utilization if you can't seem to use the CPU or bandwidth to their fullest extent, is to run two instances of Tor per one IPv4 (assuming you have at least 512 MB of RAM per instance on the server, i.e. at least 1GB for two). -- With respect, Roman
Thank you for the note, Roman. On 08/05/2015 12:07 PM, Roman Mamedov wrote:
On Wed, 5 Aug 2015 10:58:30 +0100 Tim Sammut <tim@teamsammut.com> wrote:
That said, it raises the partially-rhetorical question: should I spend my $x/month on running a relay or could that money be better used in other places?
Generally depends on if you are getting a good deal on bandwidth, i.e. how many terabytes per month for your $x. But I see you are running a relay in Costa Rica, where servers and bandwidth must be much more expensive than e.g. in Europe. I'm not sure how useful a relay in an exotic location, if it's expensive to run and pushes very little traffic. Maybe others can comment.
I think it is reasonably priced; $20USD/month for unmetered 100Mb/s. I am willing to contribute money to Tor because I believe in what it supports. I also believe in small and local businesses, which is why I have the relay in CR where I lived at the time. So perhaps to reframe my question as something more concrete. If someone is going to support the Tor project with $20/month, should they: - Run what seems like a high-capacity non-exit? - Run a handful of bridges? - Send them $20 every month? I realize this is a moving target--although it would be nice to understand generally--and it ignores putting the $20/month into other projects, organizations, more beer, etc. hope you are well tim
Am Mittwoch, 5. August 2015 13:26 schrieb Tim Sammut <tim@teamsammut.com>:
Thank you for the note, Roman.
On 08/05/2015 12:07 PM, Roman Mamedov wrote:
On Wed, 5 Aug 2015 10:58:30 +0100 Tim Sammut <tim@teamsammut.com> wrote:
That said, it raises the partially-rhetorical question: should I spend my $x/month on running a relay or could that money be better used in other places? Generally depends on if you are getting a good deal on bandwidth, i.e. how many terabytes per month for your $x. But I see you are running a relay in Costa Rica, where servers and bandwidth must be much more expensive than e.g. in Europe. I'm not sure how useful a relay in an exotic location, if it's expensive to run and pushes very little traffic. Maybe others can comment. I think it is reasonably priced; $20USD/month for unmetered 100Mb/s.
I am willing to contribute money to Tor because I believe in what it supports. I also believe in small and local businesses, which is why I have the relay in CR where I lived at the time. Now thats great! If youre able to run a relay in "exotic Places" you should do so imho. It increases diversity of the whole network. So far its more beneficial as running a relay in high density areas or more common places! Just as using small business provider instead of the common big and maybe cheaper ones.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Since 2015-08-02 consensus-health checker is reporting:
ERROR: The following directory authorities are not reporting bandwidth scanner results: maatuska, longclaw
-----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVwRDXAAoJEFv7XvVCELh0WcYQAIQGzR+n9MkjLUDY4ZLJLre4 FVAOeVPXeDbkoA/bBme+LDHG9+CcMV0P9myvfG5EHYR80SkrKvKl9EZrrKDUIGcu FBd59KlgZ+h8+N4ARggReyLfmSLRbjol7gyfPC1SR9CBwjaIphk1WE6jjYB7x2dy 9TaqJvSIYoy9DxIb/Wi1bp5YY0qOfCTZHH76ws3zACH6wKgnuC4chlJ8MgRYbdBH g8rvnLwJXCEgGetG3MCcvaSxO+PzesbZXfBvf7KObjJndHXKFCR3964IgjlJZvQ2 aeyrUItCI5PzLwiPHThGDqPfw7nW7iZqsuvcfN7GUnk4UxKTFce3qQVVnio2LC3f TGui4vuDpgORhbCtkgaAUbATbTiqUvbXra/A/HLrhkwdFsNlBeJUoQ3/mH3EmvN5 rkg8qG+5nLFUHZY/DOzK3/XPGd6KLUs3vnJuqkt5jKO87f0lSV9LGu4uvYgOiWuR NnkjXU8sMuDKIvohlDgCrsmKXuUY93jFIi+Cy0oekRi6i47Z2m45kwpjzexngDad BYsR/JwUkeHcOzs67q7IuuurtVZLoRGztx0WsmvfwhwzZdQqEnpUl0P/NgTw18aU q9BA3Sb7nS4MUOdGxhSafozZB9ABbcdAt7/oi1LLug8KmLkXvOsk1HZ5vJW7lh3H a7spJfkE2Ca/IgzQPN5a =NLaW -----END PGP SIGNATURE-----
Strange thing: My relay [0] is speeding up since then significantly (finally!!)… Cheers, Jannis [0] https://atlas.torproject.org/#details/8827944C4BDCBDAC9079803F47823403C11A9B...
On 04.08.2015, at 21:21, nusenu <nusenu@openmailbox.org> wrote: Since 2015-08-02 consensus-health checker is reporting:
ERROR: The following directory authorities are not reporting bandwidth scanner results: maatuska, longclaw
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
participants (10)
-
Jannis Wiese -
Mike Perry -
nusenu -
Roger Dingledine -
Roman Mamedov -
s7r -
starlight.2015q2＠binnacle.cx -
Tim Sammut -
Tom Ritter -
tor-server-creator＠use.startmail.com