On Friday, 21 March 2025 14:54 mail@xxxxxxxxxxxxxxxx wrote: > Mar 21, 2025, 14:10 by Tor at 1AEO <tor@xxxxxxxx>: > > 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@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!
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