It was my impression from reading some older documents that tor didn't multithread well.  Its also been my observation, but wanted a sanity check to see if that was still the case.  For instance, on one quad core low-power system I had, tor would max out at 28% of CPU - using 100% of one core and about 12% of a second (for a total of 112/4 = 28% of the system).

On 5/27/2022 12:55 PM, Roman Mamedov wrote:

On Wed, 25 May 2022 19:31:41 -0500 Thoughts thoughts@kevinsthoughts.com wrote:

...

For a non-exit relay, is "NumCPUs 2" still the recommended maximum? Running on a quad core and recently saw a message indicating I had insufficient CPU power to support the desired number of connections...

I'm not sure why would it be "the recommended maximum" to begin with.

It would make sense in context of running 2 instances of Tor on a 4-core machine, to limit each to 2 CPUs, and then pin them to cores 0-1 and 2-3 respectively with "taskset", for better cache locality and to ensure they never interfere with each other.

Running only 1 instance with "NumCPUs 4" will not be as effective in total throughput as the setup described above. But if you aren't going to run a 2nd instance in any case, there's nothing to stop you from setting that to 4, or removing that line altogether and letting Tor autodetect the number of cores.

Roger Dingledine arma@torproject.org wrote:

On Wed, May 25, 2022 at 07:31:41PM -0500, Thoughts wrote:

...

For a non-exit relay, is "NumCPUs 2" still the recommended maximum??? Running on a quad core and recently saw a message indicating I had insufficient CPU power to support the desired number of connections...

I would suggest leaving NumCPUs alone, and let Tor use as many cores as you have. Setting it to 2, when you have more cores than that, will limit how much Tor can scale.

Does tor default to using the number of cores? Or the number of logical CPUs?

And that message you saw, which I assume was "Your computer is too slow to handle this many circuit creation requests!", is exactly about the number of cores that are allocated to handling incoming create cells.

There are three main pieces to Tor's crypto, and two of them (TLS and AES) are bottlenecked on the main thread, but one of them (circuit handshakes) *does* parallelize pretty well.

So if your Tor is complaining about not being able to keep up with circuit creation requests... consider removing the artificial limitation of setting NumCPUs lower than it wants to be. :)

I am running tor at present on an ancient machine with a QX9650 CPU, so the CPU and LCPU counts are equal, both 4. If I let it default or set NumCPUs 4, then at some point tor complains that it has to drop circuits due to timeouts. The chip is ancient, but quite speedy for its time, and I've bumped the multiplier from 9 to 10, so it runs at 3.333 GHz. I have found through gradual increments of NumCPUs that 10 are not quite enough to cover all situations that arise over a lengthy uptime, so several weeks ago I increased it once again, this time to 12. Thus far tor seems happy with that number.

Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************