tor-relays

tor-relays@lists.torproject.org

36 participants
4815 discussions

most hibernating relays wake up at the same time
by nusenu 07 Aug '15

07 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, most hibernating relays with daily quotas start relaying traffic at 0:00 local time. The timezone introduces some distribution but most relays are located in UTC +02:00 so most of them start relaying at 22:00 UTC. If you run a hibernating relay and want to spread your resources more evenly you can set a non-default AccountingStart time, simply choose HH:MM in that setting as you wish. (yes, AccountingStart != wakup time, but in practice it is the case for most hibernating relays with daily quotas) If someone has stats on when the tor network needs most bandwidth during the day it might makes sense to set AccountingStart accordingly - - to add bandwidth when most users need it. (but bw doesn't seem to be an issue currently..) Reference: https://trac.torproject.org/projects/tor/ticket/16723 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVw9GgAAoJEFv7XvVCELh08iEP+wQ0F0+62ktQhR8fCFe+9yLS HacxpzLMG/4jDL0MmimVqCr5Ql9P05CXKzLse7ItEWNn5PlEkZ6z37DlQ9ctNgjY EwMlXZc1z+gLWRtHaWy6Yd0YUWkOfVfRu3bO2QDa5AN1/cEGv6+R8ddm1Ny2Mfem 5zMILOR3tofVNtpyFlahUQDEf2wQuZBMwmpYykD3I2+MfnOoeTe2AXHmgwtMdaNQ +CG+dEp8DueIYINqkYBWzmBZyTjtv3Z/ADHqyUDqFdwEsSWeC54Yb/2fZh1IEJub 383Zvhb4T3LRF2dUvKRFSCzTZl6FqZ4R1W2RvRV2Hg7xXtllbFUC/jY5i7zuJfe0 /aA5ZUv5+Rrqk7uOJpLaf6sXJGJBwCL1W5qDEtoZzQjHxbA8TFBQFYXtEfRUKiXA AiBFaJ+eLJlyztt38B6FxkN8auC25Y8csFtwcj25b8zykN4t+sFbrJvqy9r+dpzC klUlJuAlj3Oljjo4Ppd02k47yxmkc17e3TT5wm6tI2k8ZX7cD4GrK5ely+lxh/iz uceyEb7vphliJwt/slLQl9/wtg8dLvdIrpZ/rRO8uCVubSNodUuoyvuAtWn+xjsp BvwrCL0u6C/tkzRWR6OZPpuepnMk3vil9lNRkKuOadKnr2rihFb6qXgZg0RKpQDu IWCw2pXlUbbycW7K84Go =IYU/ -----END PGP SIGNATURE-----

3 4

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays