[tor-dev] Is Arti expected to have better multi-CPU support than C-tor?

[Nick Mathewson]

On Tue, Mar 7, 2023 at 4:07 PM David Fifield <david at bamsoftware.com> wrote:

> Linus Nordberg and I are preparing a submission for FOCI about the
> special way we run tor on the Snowflake bridge. We run many tor
> processes with the same identity and onion keys, because otherwise tor
> being limited to one CPU would be the main bottleneck.
>
> I'm writing to fact-check a claim about Arti and how we hope the current
> complicated procedure will not be needed in the future:
>
>         The first and most important bottleneck to overcome is the
>         single-threaded nature of the Tor implementation.² A single Tor
>         process is limited to one CPU core: once Tor hits 100% CPU, the
>         performance of the bridge is capped, no matter the speed of the
>         network connection or the number of CPU cores
>
>         ²We expect that Arti, the in-progress reimplementation of Tor,
>         will be natively multi-threaded, and remove this primary
>         complication.
>
> Is this correct? Is a relay that uses a future version of Arti expected
> to be able to use all its CPU resources?
>
>
Yes, that's right.  There is no "main thread" in Arti; it's written in an
asynchronous task-oriented style, and we use a runtime written in Rust
(Tokio by default, but we abstract them so you can swap them out) to
schedule tasks across multiple threads.

That said, we have spent approximately zero time so far tuning this
multithreading, and I'd be surprised if it scales perfectly the first
time.  Our first opportunity to show off here will be when we get onion
service support later in this year.

cheers,
-- 
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20230308/49e014d3/attachment.htm>