How effective is "NumCPUs"?
Hello, a relay I'm running is currently at about 0.80 load average. It has a dual-core CPU and I have configured "NumCPUs 2". I'm still in the process of finding the bandwidth limit. Should I keep increasing "RelayBandwidthRate" on the single Tor process, or is it a better idea to start a second process? (Also, does a second process need its own identity, or can it use the existing one?) Best regards, Alexander -- PGP Key: 0xC55A356B | https://dietrich.cx/pgp
On 01/24/2014 10:49 AM, Alexander Dietrich wrote:
Hello,
a relay I'm running is currently at about 0.80 load average. It has a dual-core CPU and I have configured "NumCPUs 2". I'm still in the process of finding the bandwidth limit.
Should I keep increasing "RelayBandwidthRate" on the single Tor process, or is it a better idea to start a second process?
(Also, does a second process need its own identity, or can it use the existing one?)
You will have to run another Tor process, with its own identity. See https://www.torservers.net/wiki/setup/server#multiple_tor_processes -- Moritz Bartl https://www.torservers.net/
On Jan 24, 2014, at 10:49 , Alexander Dietrich wrote:
Hello,
a relay I'm running is currently at about 0.80 load average. It has a dual-core CPU and I have configured "NumCPUs 2". I'm still in the process of finding the bandwidth limit.
Should I keep increasing "RelayBandwidthRate" on the single Tor process, or is it a better idea to start a second process?
In my experience, CPU load does not depend much on the amount of traffic, but much more on the number of connections/handshakes.
I've got arround 200 mbits with an Intel Xeon E3-1230v2 (not over 30% total cpu usage - 1 core at ~100%). Pretty slow for an dedicated gigabit connection, due to this fact i've killed my nodes. The ticket for this "problem" is still not solved, after 3 1/2 years. :[ quote from the ticket(would sign that): May I suggest to get this at critical priority? 21th century crypto software can't afford to be not fully-threaded ;) No CPU sold today is mono-core anymore, and I sure few people would run a tor dedicated relay up 24/24 to see it used at only 1/n'th of its capacity.
On Jan 24, 2014, at 10:49 , Alexander Dietrich wrote:
Hello,
a relay I'm running is currently at about 0.80 load average. It has a dual-core CPU and I have configured "NumCPUs 2". I'm still in the process of finding the bandwidth limit.
Should I keep increasing "RelayBandwidthRate" on the single Tor process, or is it a better idea to start a second process? In my experience, CPU load does not depend much on the amount of traffic, but much more on the number of connections/handshakes.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Or, you know, you could just run one tor daemon per core as has been suggested. Thanks for your understanding and your patience with us while we work on this and a couple other slightly difficult and pressing engineering problems. Christian Dietrich:
I've got arround 200 mbits with an Intel Xeon E3-1230v2 (not over 30% total cpu usage - 1 core at ~100%). Pretty slow for an dedicated gigabit connection, due to this fact i've killed my nodes. The ticket for this "problem" is still not solved, after 3 1/2 years. :[
quote from the ticket(would sign that):
May I suggest to get this at critical priority? 21th century crypto software can't afford to be not fully-threaded ;) No CPU sold today is mono-core anymore, and I sure few people would run a tor dedicated relay up 24/24 to see it used at only 1/n'th of its capacity.
On Jan 24, 2014, at 10:49 , Alexander Dietrich wrote:
Hello,
a relay I'm running is currently at about 0.80 load average. It has a dual-core CPU and I have configured "NumCPUs 2". I'm still in the process of finding the bandwidth limit.
Should I keep increasing "RelayBandwidthRate" on the single Tor process, or is it a better idea to start a second process? In my experience, CPU load does not depend much on the amount of traffic, but much more on the number of connections/handshakes.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Mike Perry
On Fri, 24 Jan 2014 13:38:02 -0800 Mike Perry <mikeperry@torproject.org> wrote:
Or, you know, you could just run one tor daemon per core as has been suggested.
Sadly this still limits us to just two daemons per one IP. Almost every server CPU today is at least quad-core, but servers still come with one IPv4 by default (and ordering more IPv4 carries an ever-increasing additional cost). To make it easier utilizing multiple cores, I suggested earlier that the limitation of two relays per IP is raised to 3 or 4. Perhaps with the condition that all of these also define MyFamily with each other. -- With respect, Roman
Sebastian, Jobiwan, Moritz, thanks for your responses! It seems like the machine might be able to utilize its 100 Mbit link with only one process, but running two processes is definitely a safe bet. So I guess I'll do that. Best regards, Alexander --- PGP Key: 0xC55A356B | https://dietrich.cx/pgp On 2014-01-24 10:49, Alexander Dietrich wrote:
Hello,
a relay I'm running is currently at about 0.80 load average. It has a dual-core CPU and I have configured "NumCPUs 2". I'm still in the process of finding the bandwidth limit.
Should I keep increasing "RelayBandwidthRate" on the single Tor process, or is it a better idea to start a second process?
(Also, does a second process need its own identity, or can it use the existing one?)
Best regards, Alexander -- PGP Key: 0xC55A356B | https://dietrich.cx/pgp _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Fri, Jan 24, 2014 at 4:49 AM, Alexander Dietrich <alexander@dietrich.cx> wrote:
Hello,
a relay I'm running is currently at about 0.80 load average. It has a dual-core CPU and I have configured "NumCPUs 2". I'm still in the process of finding the bandwidth limit.
So, others have answered pretty well, but I'll add a little too. Right now, Tor uses multiple cores to parallelize circuit extension handshakes, but not much else. I'm hoping that in future versions we can make serious progress on getting more of our crypto parallelized[*] to better take advantage of more cores, but for right now, NumCPUs is a good thing, but is not actually adequate for evenly dividing your Tor process's CPU load among a larger number of cores. [*] See eg discussion at https://trac.torproject.org/projects/tor/wiki/org/projects/Tor/Multithreaded... . The design there is still sound, but it needs some C hackers with spare time. -- Nick
On Fri, Jan 24, 2014 at 01:27:54PM -0500, Nick Mathewson wrote:
So, others have answered pretty well, but I'll add a little too.
Right now, Tor uses multiple cores to parallelize circuit extension handshakes, but not much else. I'm hoping that in future versions we can make serious progress on getting more of our crypto parallelized[*] to better take advantage of more cores, but for right now, NumCPUs is a good thing, but is not actually adequate for evenly dividing your Tor process's CPU load among a larger number of cores.
[*] See eg discussion at https://trac.torproject.org/projects/tor/wiki/org/projects/Tor/Multithreaded... . The design there is still sound, but it needs some C hackers with spare time.
The design is solid, and a respectable chunk of it got written, but it took longer than I thought and I got distracted with other foreground-priority things at some point, IIRC. I should rebase it against current master and get back to it at some point. -- Andrea Shepard <andrea@torproject.org> PGP fingerprint (ECC): BDF5 F867 8A52 4E4A BECF DE79 A4FF BC34 F01D D536 PGP fingerprint (RSA): 3611 95A4 0740 ED1B 7EA5 DF7E 4191 13D9 D0CF BDA5
participants (8)
-
Alexander Dietrich -
Andrea Shepard -
Christian Dietrich -
Jobiwan Kenobi -
Mike Perry -
Moritz Bartl -
Nick Mathewson -
Roman Mamedov