Opened 6 years ago

Closed 6 years ago

#9005 closed enhancement (duplicate)

"Your computer is too slow" -> improving multithreading of "circuit creation requests"?

Reported by: elgo Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version: Tor: 0.2.3.25
Severity: Keywords: thread slow cpu circruit creation
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Hi,

I'm seeing some tor behavior we used to see in past I2P versions: new connections handling is quite hogging, probably because it is not really spreading its load on every cores available. I mean, CPU is globally almost only 33% used, but tor complains about it being too slow, and suggests lowering MaxAdvertisedBandwidth, which is finally "a waste".

I2P worked on this and now overall bandwith usage has dramatically increased, and CPU is better used.

Is there a way to improve the parallelism of "circuit creation" handling in tor?

Child Tickets

Change History (4)

comment:1 Changed 6 years ago by nickm

Circuit creations are already handled in parallel. Tor 0.2.4.x introduces a faster algorithm for circuit creation crypto, and an adaptive queue that aims to ensure a maximum queue size in time rather than in lenth.

comment:2 in reply to:  1 ; Changed 6 years ago by elgo

Replying to nickm:

Circuit creations are already handled in parallel. Tor 0.2.4.x introduces a faster algorithm for circuit creation crypto, and an adaptive queue that aims to ensure a maximum queue size in time rather than in lenth.

Ok, but then if the parallelism is ok, how can we explain this "top" extract (4 cores):

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2277 debian-t 20 0 535m 353m 27m R 99,7 17,7 6117:27 tor
2447 debian-t 20 0 535m 353m 27m S 13,6 17,7 429:43.70 tor
2448 debian-t 20 0 535m 353m 27m S 8,0 17,7 217:40.87 tor
2450 debian-t 20 0 535m 353m 27m S 4,3 17,7 127:57.62 tor
2449 debian-t 20 0 535m 353m 27m S 3,0 17,7 85:47.48 tor

PID 2277 is the main tor process, other 4 are tor threads (which is fine as this CPU has 4 cores). But obviously tor is struggling in 2277, which I suspect is the only one dealing with "circuit creation requests". 2277 is caped at 100% CPU (of course) and execution time shows a really uneven load balancing between all these gentlemen (at best, PID 2447 has only 7% of PID 2277 execution time).

That, would explain why tor is complaing about a "slow computer" (which, in fact, it is, but not that slow :)), when CPU has so much more to offer.

comment:3 in reply to:  2 Changed 6 years ago by nickm_mobile

Replying to elgo:

Replying to nickm:

Circuit creations are already handled in parallel. Tor 0.2.4.x introduces a faster algorithm for circuit creation crypto, and an adaptive queue that aims to ensure a maximum queue size in time rather than in lenth.

Ok, but then if the parallelism is ok, how can we explain this "top" extract (4 cores):

I didn't say parallelizing was okay: I said that circuit creation (which is what you were asking about) was handled in parallel. Server-side circuit creation is approximately the ONLY thing handled in parallel, though. :/

You might want to check out the other tickets related to parallelizing other stuff: there's one for parallelizing relay crypto (shouldn't be too tough) and another for parallelizing openssl stuff (likely to be trickier). (Sorry for notforthose finding the numbers for those; I'm on my phone right now)

comment:4 Changed 6 years ago by elgo

Resolution: duplicate
Status: newclosed

Ok, I found this https://trac.torproject.org/projects/tor/wiki/org/projects/Tor/MultithreadedCrypto

I suppose I can close this bug and "follow" the other one (#1749)
Thanks.

Note: See TracTickets for help on using tickets.