Glad to see Nusenu's statistics pages are as useful for others as they are for me! And there's interest in higher frequency updates.
How best to contact Nusenu? Rough ideas on the range of costs?
Seems like the effort required to comply with AROI is worth having a dedicated statistics page. I'll keep working on the AROI support.
On Saturday, March 22nd, 2025 at 12:29 PM, boldsuck via tor-relays tor-relays@lists.torproject.org wrote:
On Friday, 21 March 2025 14:54 mail@nothingtohide.nl wrote:
Mar 21, 2025, 14:10 by Tor at 1AEO tor@1aeo.com:
How best to find out these 20% and 10% values at any point, especially as they fluctuate?
Nusenu's OrNetStats is the best source I have found to check on relay operator/family statistics, operating systems statistics etc. But as you have already found out as well, it refreshes only once per month or so, limiting it's usefulness. It used to be pretty much daily in the past, but it seems this isn't maintainable anymore. And with fair reasons.
I can only agree that Nusenu's OrNetStats is the best source. Once you have configured AROI: https://nusenu.github.io/OrNetStats/#authenticated-relay-operator-ids
you will have your personal page: https://nusenu.github.io/OrNetStats/for-privacy.net.html https://nusenu.github.io/OrNetStats/nothingtohide.nl.html
AFAIK, the fact that updates are no longer daily is a question of cost. The millions of database queries cost money. The database was sponsored by someone for nusenu for a while.
I suggest contacting Nusenu if you need more frequent updates. Previously Nusenu was looking for use-cases that warranted increasing the update frequency. NTH would also benefit from more frequent updates, but we're hesitant to pressure people who volunteer their spare time for these kind of (awesome) projects in to spending even more time.
Seems a waste to negotiate a five year financial colo or server contract when the Tor network doesn't want it due to lack of sufficient diversity?
The 20% of exit capacity is indeed not a lot so you will probably reach the required amount of exit consensus weight relatively easy/fast. But the 10% cap on overall consensus weight on the other hand provides a bit more headroom for some additional guard/middle relays. So you could just start with exit relays and then check the exit consensus weight every now and then. When you hit 20%, just convert a few relays to guard/middle relays.
When you add tens of gigabits to the network, you will also increase the network size, effectively providing more exit relay headroom for other Tor operators and yourself as well. The more operators, the more everyone can grow their relays before hitting the cap. It's not perfect, but the Tor project values diversity more than increasing network capacity/speed so there is not much we can do about this. I'd say: don't go overboard with 5 year contracts. Maybe start with 20 Gb/s and then increase by chunks of 10 Gb/s when there is enough headroom. Good luck,
tornth
On Monday, March 10th, 2025 at 7:34 AM, boldsuck via tor-relays <tor-
relays@lists.torproject.org> wrote:
On Sunday, 9 March 2025 22:59 Tor at 1AEO via tor-relays wrote:
New constraint - any guidance? Math seem right? All relay operators / families are limited to a maximum of ~360 Tor relays: https://gitlab.torproject.org/tpo/core/tor/-/issues/40837 I'll likely create an account to reply on the gitlab ticket too since looks like different audience than those replying here.
Unfortunately, if the Tor network isn't efficient in using the bandwidth across ~4 x 10 Gbps servers then this limit will be reached, hindering known good operators, while not stopping malicious operators who don't follow the rules. Least efficient, ~512 CPU threads / relays for 4 x 10 Gbps (128 threads/relays per 1 x 10 Gbps server). Most efficient, ~320 CPU threads / relays for 4 x 10 Gbps (80 threads/relays per 1 x 10 Gbps server).
Today, optimize Tor relay for the ~360 constraints:
- Maximize bandwidth per CPU thread/core/relay with higher CPU base
clock 2) Other hardware: Ensure sufficient RAM per Tor relays (4GB to 1 CPu thread) and good NIC. 3) Maximize network peering / routing strategies for Tor? Anything else?
With so many relays per Family/Operator you also reach the 20% and 10% limits and /16. And you have to be able to pay the bandwidth costs. A 10G relay does 100TB/day and several PB per month.
For #3, how best to optimize network routing / peering strategies for Tor relays? This email thread was optimizing around CPU threads and RAM but having plenty of CPU threads and RAM that might be insufficient with a poor network routing/peering strategy for Tor? Is there a reasonable way or some reliable way to quickly (less than a few months of running the relays) get in the correct range of how well the Tor network uses a specific server's available bandwidth? Ex: Route hops / ping times to directory / bandwidth authorities, confirming well known upstream providers (Cogent, etc.), and/or something else? Best strategy is month-to-month renting servers and running relays rather than signing 5 year contracts to end up somewhere with poor peering/routing for Tor?
The Tor network is a dynamic massive network and bandwidth contributions and overall consensus weight are constantly changing. When a larger operator (like NTH or RWTH Aachen) goes up or down everything changes. In addition, the Tor network team and DirAuth's may change consensus rules at any time.
Diversity is important and that relays and bridges are running at all. How big an operator can be will also be a big issue when Arti and Family keys arrive. Because relayon reached 25% exit cw, the IPs were split between several orgs.
-- ╰_╯ Ciao Marco!
Debian GNU/Linux
It's free software and it gives you freedom!_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org