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-happy-families.md 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@xxxxxxxxxxxxxxxxxxxx> 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 -- tor-relays@xxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx