Hi, Mar 21, 2025, 14:10 by [email protected]:
> 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 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 > <[email protected]> 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: >> > 1) 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 -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > tor-relays mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ tor-relays mailing list -- [email protected] To unsubscribe send an email to [email protected]
