tor-relays August 2015

tor-relays@lists.torproject.org

58 participants
59 discussions

Guard flag flapping
by Green Dream 07 Aug '15

07 Aug '15

I have two relays on the same Gb/s connection. I followed the optimization tips offered in another thread, and think I have things running reasonably well. What I don't understand is why the Guard flag keeps flapping back and forth on both relays. https://atlas.torproject.org/#details/89B9AE4C778DE44AFFAB791093E19979616E6… https://atlas.torproject.org/#details/11A579CC6CEE644A390704977B70CBA8D8347… If you look at the 1 week graph of weights, you'll see what I mean. I haven't been able to find any documentation or explanation for this behavior. Anyone have any thoughts on why this might be happening, or any pointers on how to further investigate?

1 0

longclaw BWauth is back, not measuring 2000 relays, what's with that?
by starlight.2015q3＠binnacle.cx 06 Aug '15

06 Aug '15

The explanation does help--thank you. Have been interested in how it would look after the script update since 7/28 (nine days ago) but did not realize it took so long to rebuild the data.

1 0

longclaw BWauth is back, not measuring 2000 relays, what's with that?
by starlight.2015q3＠binnacle.cx 06 Aug '15

06 Aug '15

longclaw 4691 Measured values in w lines maatuska 6815 Measured values in w lines gabelmoo 6347 Measured values in w lines moria1 6715 Measured values in w lines

2 1

BWauth no-consensus state in effect
by starlight.2015q2＠binnacle.cx 06 Aug '15

06 Aug '15

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.

10 12

Blutmagie does not see 0.2.7.2 bandwidth
by starlight.2015q3＠binnacle.cx 05 Aug '15

05 Aug '15

>At Tue Aug 4 11:22:22 UTC 2015 by Olaf Selke olaf DOT selke at blutmagie DOT de > >by the way... I will probably shut down blutmagie >tor network status in September this year cause >the data center has terminated the contract >housing my servers 10/31/15. Could you make your modified Torstatus code available on https://gitweb.torproject.org/torstatus so that someone else can set up another like it? Blutmagie appears to have significant and desirable enhancements to the code presently in the GIT repository. I might contribute a new Torstatus, but if not me someone surely will.

2 1

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 05 Aug '15

05 Aug '15

Maybe geo-location would not be so great because two networks in the same physical area might have relatively poor connectivity to each other. Aggregated IP block might be the ticket. CIDR-Report has both actual and suggested netblock aggregations. http://www.cidr-report.org/as2.0/#Gains Shows 562259 reduced to 253420 advertisements. Perhaps too fine-grained, but 250k is not so much bigger than the 45k ASN count. Idea is to anchor metrics to maximum size BGP routable blocks, which ought to correlate performance-wise down to all the IPs in each block. >>BWauths are continuously pairing relays for >>measurements, and perhaps metrics from that >>could be mapped to autonomous system numbers > >. . .scratch AS, geo-location is >better and MaxMind specializes in that > >Pinging a FiOS relay in LA takes >75ms while a close-by relay takes >8ms. Both are in AS 701.

1 0

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 05 Aug '15

05 Aug '15

>BWauths are continuously pairing relays for >measurements, and perhaps metrics from that >could be mapped to autonomous system numbers . . .scratch AS, geo-location is better and MaxMind specializes in that Pinging a FiOS relay in LA takes 75ms while a close-by relay takes 8ms. Both are in AS 701.

1 0

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

At Tue Aug 4 22:17:54 UTC 2015 by Mike Perry mikeperry at torproject dot org > >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. > Perhaps the guard-selection algorithm could be enhanced to consider some sort of distance/reachability metric generated by BWauths? BWauths are continuously pairing relays for measurements, and perhaps metrics from that could be mapped to autonomous system numbers (from MaxMind) in a useful way without requiring tremendous effort? Matrix analysis comes to mind. If one's guard is on the other side of the world, network latency and random congestion will hurt. I've read some path selection research is under way with an eye toward reducing passive traffic correlation exposure--this seems like it would help performance in a similar way.

1 0

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

Many under-utilized and never-utilized exits relays back online with BWauth outage. Unscientific sample out of 234 previously Unmeasured=1 exit relays, but almost all of the ones checked are like these https://atlas.torproject.org/#details/0D7739DEF50470356744440435FED9E1F57EF… https://atlas.torproject.org/#details/1E014CF541F32F377A116E78B76A603B8346A… https://atlas.torproject.org/#details/2316E6F012ACA52FDB09C745B0F5B41E78C23… https://atlas.torproject.org/#details/2A63402166192D66018D3FCB1ED8DE740CE71… https://atlas.torproject.org/#details/37C49200E04C8FE70799430718B10CEA5DBFB… https://atlas.torproject.org/#details/47BDCB56A9CCDAAAA71D74549E388C8EA1265…

2 1

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

Poking around Blutmagie, I suspect the number of relays with chopped bandwidth weightings might be more like in the range of 25-45. Perhaps the PID-controller algorithm should be adjusted to bias somewhat less toward super-fast relays.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays August 2015