Hi,

No network experience but already running 2 TOR instances: 1 TOR service + 1 bridge.

Very nice! You're asking some great questions and I'll try to answer as many as I can :).

My preferred choice at the moment is [3] where I would like to have 3 relays (one of each type; 3.5 GB RAM needed).

In most cases guard and middle relays are the same thing (they are both at the same time in most cases). So in your case, instead of hosting one guard, one middle and one exit, it probably makes more sense to host two guard/middle relays and one exit relays (or one guard/middle and two exits, which probably is more useful tot he network).

The [TOR-friendly] ISP I'm looking at have these 4 offers available:

Are these monthly bandwidth allowances tx/rx (send + receive traffic) combined or based on the highest of the two? In the former, you would only have half of it effectively since Tor's traffic is more or less symmetrical in nature. That's good to know beforehand.

I'm running a few exit relays on a basic VPS with one similar core and 2GB of ram and those move ~23 TB a month (rx+tx combined). Do note that this VPS provider has extremely poor CPU performance that doesn't even come remotely close to proper virtualized CPU performance (let alone bare metal). But this being the case and assuming the VPS provider you are looking at has similar or better CPU performance, you will easily move more traffic than the monthly allowance on any of their offerings. In other words: without a increase in monthly allowance your CPU will either be idle for a large portion of the month (e.g. AccountingMax) or will be idling a lot (e.g. BandwidthRate).

If you think that's undesirable, you might inquiry about increasing the monthly allowance beforehand or look for another provider. But on the other hand, it will still be useful to the Tor network and you will also be able to learn and get experience from such a setup (which is one of your goals) so there also is nothing wrong with going with one of the options you mentioned :-).

From relay requirements https://community.torproject.org/relay/relays-requirements/, my understanding is that [1] is what is expected for a guard or middle relay and [2] for an exit relay.

Although these memory requirements are fine to use as a 'bare minimum', it will change a lot when multiple relays are being hosted. For example, if I would take the requirement page literally I would need 60 GB of ram for my Tor relays (40 per server), but in reality they never come even close to 30% of that. Running a few relays on 1-2 CPU cores with limited RAM is fine, but just keep an eye on it and don't run other memory intensive stuff on the server (like DNS query caching, which can take quite some RAM as well).

I guess my fundamental question is what is the advantage of running multiple relays of the same type, on the same server? I see some operators running dozens of them, all in the same country, same ISP. Why not just a single relay running with a large capacity?

Sadly the current Tor relay software can't use multiple cores effectively, so it won't scale at all on multi thread CPU architectures. Ideally I would run one relay per server, but because of this limitation in Tor's architecture the only other way to utilize the CPU to its full potential is by running many relays.

Also, is there a requirement for the number of relays per core? (Maybe this is the answer to my question.)

Not really, unless you're really optimizing for max. bandwidth per CPU. You could run one relay per physical core, one relay per thread or even multiple relays per thread on modern hardware and it wouldn't matter much as long as there is enough headroom for the memory overhead of multiple processes. In my experience, one relay per CPU core isn't enough to saturate a modern CPU. Even running one relay per thread (in the case of SMT) often isn't enough.

But in a lot of cases people run Tor relays on type 1 or type 2 hypervisors with OS virtualization (typical VPS providers), and then the OS that you use for Tor won't have control over the CPU threads and hence can't optimize this meaningfully. In that case it depends more on the amount of RAM (which is often limited on cheap VPS) you have available for running additional relays.

I know my bridge is currently keeping one core of my 2-core server constantly under load.

If your monthly bandwidth allowance, bandwidth and electricity consumption allow for it, then I would always advise to run more relays to use the CPU more effectively. It's a waste of good CPU cycles to not saturate it! ^_^

Hopefully this was useful to you and don't hesitate to ask more or follow-up questions!

Cheers,

NTH

Mar 7, 2023, 08:14 by sydney+tor@liaison.club:

Newbie here. No network experience but already running 2 TOR instances: 1 TOR service + 1 bridge.

I would like to "upgrade" to TOR relays but have a few questions relating to hardware needs.

The [TOR-friendly] ISP I'm looking at have these 4 offers available:

[1] 1 core @ 3.1GHz 1 GB RAM 10 TB/mo @ 5 Gbps BW

[2] 1 core @ 3.1GHz 2 GB RAM 10 TB/mo @ 5 Gbps BW

[3] 2 core @ 3.1GHz 4 GB RAM 20 TB/mo @ 5 Gbps BW

[4] 3 core @ 3.1GHz 12 GB RAM 30 TB/mo @ 5 Gbps BW

From > relay requirements https://community.torproject.org/relay/relays-requirements/> , my understanding is that [1] is what is expected for a guard or middle relay and [2] for an exit relay.

My preferred choice at the moment is [3] where I would like to have 3 relays (one of each type; 3.5 GB RAM needed). Each relay would be limited to, say, 6.6 TB/mo BW. This would allow me to experiment and get used to the network and its requirements.

My questions is about future increase. If I want to increase my offer to the TOR network I could:

Negotiate with my ISP to increase my BW to 30 TB/mo while still running on [3] and increase each BW limit to 10 TB/mo; Move my 3 relays on [4] and increase each BW limit to 10 TB/mo; Move my 3 relays on [4], add 2 IP addresses and 6 relays (2 of each type; 10.5 GB RAM needed total), and limit each relay to 3.3 TB/mo.

I guess my fundamental question is what is the advantage of running multiple relays of the same type, on the same server? I see some operators running dozens of them, all in the same country, same ISP. Why not just a single relay running with a large capacity? Also, is there a requirement for the number of relays per core? (Maybe this is the answer to my question.) I know my bridge is currently keeping one core of my 2-core server constantly under load.

Thank in advance.

On Dienstag, 7. März 2023 03:00:49 CET Sydney wrote:

Newbie here. No network experience but already running 2 TOR instances: 1 TOR service + 1 bridge.

Never mix different relay types under one IP.

I would like to "upgrade" to TOR relays but have a few questions relating to hardware needs.

1core 2GB RAM is enough for an exit. This one: https://metrics.torproject.org/rs.html#details/D00795330D77C75344C54FB880053... 1core, 2GB RAM, 10GB Network You need bandwidth, _unlimited_ bandwidth. A relay easily has 50-100TB/month! Tor relay (=router) bandwidth is in + out!

I guess my fundamental question is what is the advantage of running multiple relays of the same type, on the same server?

Because C-tor is not multicore aware.

I see some operators running dozens of them, all in the same country, same ISP. Why not just a single relay running with a large capacity?

see above (multicore) These are very powerful servers. Mostly their own, in colocation. 1x10G, 2x10G or more network connection, 64 or 128 CPU cores 256-512 GB RAM and _unlimited_ bandwidth. In addition usually their own ASN. To advertise an AS via BGP, at least a /24 (255 IP's) is required.

That's why I keep asking when we'll finally be able to run IPv6 only relays. /24 IP + ASN approx. 5000 EUR/(1st)year. (Only via waiting list & if never received an IPv4 allocation) /48 IPv6 + ASN approx. 100 Eur/year.

https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-waiting-list

Also, is there a requirement for the number of relays per core? (Maybe this is the answer to my question.) I know my bridge is currently keeping one core of my 2-core server constantly under load. Thank in advance.

Rule of thumb - one instance per core.