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!
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-le...@lists.torproject.org
