On Friday, 21 March 2025 13:53 Tor at 1AEO wrote:
Some clarification questions:
How best to find out these 20% and 10% values at any point, especially as they fluctuate?
https://nusenu.github.io/OrNetStats
Can you say more about the expected "big issue" of arti and family keys?
Bigger families and arti is multicore aware. With one or a few IPs and instances, you can achieve 10G. https://gitlab.torproject.org/tpo/core/tor/-/issues/40837
When are they expected to arrive?
Surprise :-) suddenly there after many years: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/321-hap... https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/857
Quetzalcoatl can begin
How did relayon know they were 25% of exit cw?
https://nusenu.github.io/OrNetStats/relayon.org.html https://gitlab.torproject.org/tpo/core/tor/-/issues/40007
How did they go about splitting IPs?
Split into /26 and /27 and routed to the servers.
It'd be great for it to update more often than monthly but seems best way to view cw compared to no alternative? 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