Why are different relays getting drastically different traffic?

[clucernoni]

Hello!
I am relatively new to the world of being a relay operator. I am running 4 different VPSs in 4 different countries with multiple relays on each. I would like to help with the diversity of the relays by choosing low weighted countries. You can see my family here: Relay Search

As you can see, some of my relays are seeing drastically more traffic than others. My relays in Brazil have never seen much traffic at all and it was one of the first (I recreated it because I thought I had mis-configured something). The VPSs are the same configurations with the same config torrc.

I guess my question is - Does TOR do something to prefer certain nodes over others when it comes to locations or some other metric (Assuming availability and resources are the same)? I can’t imagine why there would be a reason to prefer Albania over a huge country like Brazil. If this is the case, then it would make the most sense to migrate the Brazil relays to a country that TOR would prefer in order to give the network more available bandwidth.

Thanks for any insights you can provide.

[Vort]

@clucernoni

Assuming availability and resources are the same

I suspect such assumption may be wrong.
Different networks usually have different properties: packet loss, bandwidth, RTT (ping).

@clucernoni

As you can see, some of my relays are seeing drastically more traffic than others.

All of them are known to the network for only 3-8 days.
Metrics shows the following message for a reason:

[1aeo]

The significant majority of top-bandwidth Tor relay contributions originate from Europe—currently, 9 of the top 10 and 18 of the top 20 relays (Relay Search) This distribution appears to heavily favor European-based relays, significantly influencing traffic patterns.

I haven’t yet come across a comprehensive technical explanation for this phenomenon. Typical advice for boosting relay traffic includes ensuring relays have been running continuously over an extended period, verifying there’s no restrictive configuration limiting bandwidth, and confirming that relays have adequate CPU, RAM, file descriptors, local ports, and robust upstream network connectivity.

To help address this imbalance and add diversity, I recently deployed several 10 Gbps relays across various US locations. After around 90 days operating guard relays, I’m observing only about 10–20% bandwidth utilization at best and as low as 1–5% at worst. Consequently, 80–90% of the bandwidth I’m purchasing is effectively unused.

My observations over the past 90 days show that my relays located in US East receive roughly twice the traffic of those in US South and approximately four times that of US West. I suspect this disparity arises primarily from the superior network connectivity between US East and Europe.

Given these costs and inefficiencies, I’ve decided to stop running relays in US West and US South. As an experiment, I’m currently following this strategy: temporarily hosting relays in Europe to establish favorable bandwidth metrics before moving the relay keys back to US-based servers to see if higher traffic levels persist. Source: 2 relay per IP limit / how to use more bandwidth - #8 by lokodlare

Aside from these experimental strategies, I’m not aware of a better short-term solution. I’d be interested to hear if others have insights or experiences addressing this issue.

Attached a visual, using metricsport and prometheus and grafana showing the relay traffic averaged across servers for the last 24 hours since I started the experiment. I used ~90 day old relays to move into Europe to speed along the experiment.
Light blue going to the top is Amsterdam.
At the bottom are orange and green for Spain and Estonia. Seems Spain is consistently not doing well, but still early.
Top red and yellow and pink are Montreal, New Jersey, and Chicago.
Middle blue is New York and Middle purple is Texas.

[clucernoni]

How interesting. I would love to continue to follow your experiment results if you are posting them somewhere.

The inefficiency is concerning given the overall need for more capacity for users as well as the potential for an improved experience in general.

[1aeo]

How interesting. I would love to continue to follow your experiment results if you are posting them somewhere.

Great - I’ll post results here for you!

After a week: All of Tor relays, once in Europe, performed better on actual measured bandwidth per relay than when they were in US South.

Moved Tor relays and keys from low performing server in US South over to Europe using 4 different servers, in 3 different geographic regions with 2 different providers. Specifically, 2 in Amsterdam with different providers and 1 in Estonia and 1 in Spain.

See measured traffic chart reported by each of the relays mentioned above, every 2 minutes, as well as the other ~200 relays running in US.
Orange = Provider 1 in Amsterdam
Green = Provider 2 in Amsterdam
Yellow = Provider 1 in Estonia
Red = Provider 1 in Spain
Blue = Provider 3 in New Jersey
Light Purple = Provider 4 in Chicago
Dark Purple = Provider 5 in California, bottom flat line, might be hard to see

[1aeo]

Another update and some conclusions.
Geographic locations: Instead of 100% deployed in the US, will switch to 50% in EU and 50% in the US so I only waste half my money on Tor under utilizing US bandwidth.
To reduce wasting money in the US, will stay around US East.
Stopped US South and US West and likely US Midwest.

Plans for servers:
Keep: orange for New Jersey and keep green for Amsterdam with upgrade server
Likely stopping: red for Chicago because Tor doesn’t allow enough relays, 360 limit and need 270, and too many threads in one server, to saturate 10 Gbps
Stop: yellow because the provider is too expensive for compute and bandwidth to saturate 10 Gbps.

Orange is New Jersey, 90 guard relays, aggregate utilizing 5 Gbps.
To saturate 10 Gbps, need 180 guard relays, calculated at 2x current, assuming linear scaling.
Capacity: 192 threads, 768GB RAM, 10 Gbps dedicated unmetered.
Utilizing: 15 load over last 15 min (top) and 460GB RAM

Red is Chicago, 90 guard relays, aggregate utilizing 3 Gbps.
To saturate 10 Gbps need 270 relays, calculated at 3x current, assuming linear scaling.
Capacity: 128 threads, 768GB RAM, 10 Gbps dedicated unmetered.
Utilizing: 23 load over last 15 min (top) and 430GB RAM

Green is Amsterdam, the same provider as red, 10 guard relays, aggregate utilizing 2 Gbps.
To saturate 10 Gbps, need 60 guard relays, calculated at 5x current, assuming linear scaling.
Capacity: 88 threads, 256GB RAM, 10 Gbps dedicated unmetered.
Utilizing: 7 load over last 15 min (top) and 44GB RAM

Yellow is Amsterdam, 6 relays, aggregate utilizing 1 Gbps.
To saturate 10 Gbps, need 60 relays, 10x current, assuming linear scaling.
Capacity: 10 threads, 32GB RAM, 10 Gbps dedicated unmetered. Temporary VPS.
Utilizing: 3 load over last 15 min (top) and 9GB RAM

Total Bandwidth

Average Bandwidth per Relay