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?
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-... 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-...
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-... 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-...
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 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-...
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-...
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.
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
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).
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
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
tor-relays@lists.torproject.org
-
Jannis Wiese -
Mike Perry -
nusenu -
Roger Dingledine -
Roman Mamedov -
s7r -
starlight.2015q2＠binnacle.cx -
Tim Sammut -
Tom Ritter -
tor-server-creator＠use.startmail.com