Re: [tor-relays] Consensus Weight Dropping/Authority Issues?
Hi John, >> On 2 Feb 2020, at 14:15, John Ricketts wrote: >> >> I have been watching the consensus weight and bandwidth of all of my 50 exit >> nodes drop consistently over the past few months. I have not made any >> hardware changes in my data center and actual >> customers have not complained about any performance issues. >> >> Operating systems and Tor version are up to date. I'm dedicating a >> significant portion of bandwidth to these nodes - 10gbit/sec. >> >> Am I having issues with the bandwidth authorities? >> >> I'm growing frustrated with my performance to resources ratio, I should be >> doing far better than this. >> >> Please throw ideas at me - open to any ideas. > > On Feb 1, 2020, at 20:05, "starlight.201...@binnacle.cx" > wrote: > > The rating shift experienced by your relays and many others is likely a > consequence of the gradual phase-in of the SBWS scanner implementation in > place of TorFlow. I for one find SWBS unimpressive. There are known bugs in both bandwidth authority implementations, sbws and torflow. Here's a list of the critical sbws bugs: https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~sbws-majority-blocker We're working on getting some funding to fix these bugs in sbws. (Torflow is very old and hard to install, most of its dependencies are unsupported. So we aren't tracking torflow bugs in detail any more.) I don't think we've added any sbws instances for a few months. And I haven't seen any specific evidence that sbws (or torflow) is responsible for these issues. If you give us a timeframe, we might be able to help more. It's also possible that there are more exits in the Tor network, or that the routing between the bandwidth authorities and your network has become slower. There are some other common explanations for slow relays, listed on this wiki page: https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow You might find some of the tips on that page helpful. Also, if you can find some authorities that are giving your relays low measurements, we might be able to find out why. You can see a copy of all the bandwidth authority measurements here: https://consensus-health.torproject.org/consensus-health.html T -- teor -- signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor version 0.4.0.x reaches end-of-life on 2020-02-02
Hi, > On 2 Feb 2020, at 23:55, nusenu wrote: > > Signed PGP part > Toralf Förster:> I do wonder if recent Tor clients do already prefer to not > choose EOL relays? > > Version information (or the recommended version list) is not part of the path > selection algorithm > of tor clients. But we do use the recommended version list to select fallback directory mirrors. So when we next rebuild the fallback list (later in 2020), all relays on 0.2.9 and 0.4.0 will be removed. Clients may use relay protocol versions to choose paths, when we add new features that they want to use. But that's a long way away. All supported Tor versions (and 0.4.0) support the most recent tor Relay protocols. So clients don't have any reason to choose between relays based on versions right now. In Tor 0.4.4, we'll introduce a new Relay protocol for IPv6 extends, to support relay IPv6 reachability checks. Clients will ignore it, until they start doing IPv6 extends. (We think we need more IPv6 relays, before clients can safely use IPv6 extends. In the meantime, clients just do IPv4 extends, and every relay has IPv4.) T -- teor -- signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor version 0.4.0.x reaches end-of-life on 2020-02-02
Toralf Förster:> I do wonder if recent Tor clients do already prefer to not choose EOL relays? Version information (or the recommended version list) is not part of the path selection algorithm of tor clients. -- https://mastodon.social/@nusenu signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor version 0.4.0.x reaches end-of-life on 2020-02-02
On 2/2/20 1:49 PM, nusenu wrote: > Currently over 10% of the network is running on end-of-life tor releases, > this is bad. I do wonder if recent Tor clients do already prefer to not choose EOL relays? -- Toralf signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor version 0.4.0.x reaches end-of-life on 2020-02-02
The table bellow should help you find out whether you run an EOL version of tor (if you set a contactInfo string). Currently over 10% of the network is running on end-of-life tor releases, this is bad. https://nusenu.github.io/OrNetStats/#end-of-life-relays-share data as of: 2020-02-02 12:00 UTC ++--+-+-+ | cw | contact | #relays | used_versions | ++--+-+-+ | 280300 | Thomas Steen Rasmussen / Tykling (PGP: 0 | 3 | 0.4.0.5 | | 254000 | Gijs Rijnders (tor AT ip-eend DOT nl)| 3 | 0.4.0.5 | | 116292 | Random Person | 6 | 0.2.9.10,0.4.0.5| | 107530 | foore...@hotmail.com | 10 | 0.2.9.17| | 104000 | DFRI - 1Muz37TfXVBiJKRJkAqTNo7MnEZN8hhm | 3 | 0.4.0.5 | | 97200 | torpids AT yahoo dot com - 1JYHfzVFVD7n2Sezz3DEHDFgGYjQWpDjq | 4 | 0.4.0.1-alpha,0.4.0.3-alpha,0.4.0.5 | | 97000 | | 1 | 0.2.9.16| | 83400 | t...@govanify.com | 1 | 0.4.0.5 | | 67200 | florentin aatt rochet ddoott be; LTC: LhRqJZu6U87BJNSUbkACHz | 5 | 0.4.0.5 | | 66500 | KeFF NOC| 1 | 0.4.0.5 | | 63000 | ab...@maytownsend.is < abuse AT maytownsend dot is> | 1 | 0.4.0.5 | | 61000 | s...@hijnn.net | 1 | 0.4.0.5 | | 61000 | Tor Reactor <0d0[AT]protonmail.com> | u42omsvzmh7momdk.onio | 1 | 0.4.0.5 | | 59000 | t...@texthtml.net | 1 | 0.4.0.5 | | 56000 | jannisd...@eclipso.eu | 1 | 0.4.0.5 | | 51370 | t...@example.org | 4 | 0.4.0.5 | | 44000 | fredreic(at)tutanota(dot)com | 1 | 0.4.0.6 | | 42000 | mail[at]nozel[.]org | 2 | 0.4.0.5 | | 38600 | OMP o...@cock.li | 1 | 0.2.9.16| | 32000 | Network Operations | 1 | 0.4.0.2-alpha | | 31000 | dev.n...@kryptonit.org - 1AjBZw8ExjkWgh7Y5s9mLX4UXHadzPfKQu | 1 | 0.4.0.5 | | 29400 | 5...@gmx.ch [tor-relay.co]| 1 | 0.4.0.5 | | 29050 | Dave Null | 4 | 0.2.9.17| | 29000 | 1Jwjq2AGPua8urdfZXtSbEQCKBQWF34qew ronstorabuse[a]protonmai | 1 | 0.4.0.5 | | 29000 | t...@moletrix.be | 1 | 0.4.0.5 | | 29000 | william.san...@hotmail.co.uk | 1 | 0.4.0.5 | | 28000 | email: torc...@gmx.net | 1 | 0.4.0.6 | | 27900 | ne...@pm.me | 1 | 0.2.9.16| | 25400 | tor-ato...@protonmail.com| 1 | 0.4.0.5 | | 25000 | jjack...@laposte.net | 1 | 0.2.9.16| | 24100 | tor atgoeshere nerdpol dotgoeshere org | 1 | 0.2.9.17| | 24000 | t...@ueno.red | 1 | 0.4.0.5 | | 23800 | tor+torro...@tzu.io | 1 | 0.4.0.5 | | 23300 | jorge | 1 | 0.4.0.6 | | 23000 | 4096R/5819E33F Zhongfu Li | 1 | 0.4.0.5 | | 22100 | pho...@protonmail.com| 1 | 0.4.0.5 | | 22000 | not-wanted [at] unknown [dot] com| 1 |
