-------- Forwarded Message --------
Some multicore support (at least 4 cores) should be a priority. Going
beyond doesn't cater to many node operators at this time. Don't quote me
on the numbers, but having decent 4-core support would let someone run a
node with the same bandwidth on an Atom/i5 that currently runs on one
thread of a Xeon. Or, if someone has a Xeon, such as a collocation
center, would let them fully utilize the processor they are paying for,
which would be a good morale boost for node operators.
But, honestly, the very minimum that can be done to improve the
situation (which I know is being worked on as of 0.2.7) is improving a
2-thread program, to further utilize 2 threads of a cpu. That way, we
can get by with 2 processes on one 4-thread CPU, instead of being
tempted to jumped to 4 processes.
On 2.6.15 11:31, Roman Mamedov wrote:
> On Tue, 02 Jun 2015 11:13:13 -0400
> 12xBTM <12xbtm@xxxxxxxxx> wrote:
>
>> Improving multi-core support can allow users to saturate high bandwidth
>> connections with cheaper processors, less setup, and just more efficient
>> deployment of high-capacity nodes in general. Improving multi-core
>> support should be a major priority.
> Sure but I doubt anyone contests that it's better to have multicore support,
> than to not have it. However that work doesn't get automatically done.
>
> One quick and simple stop-gap alternative that I suggested some time ago would
> be to stop ignoring more than two relays per IP address.
>
> With the IPv4 shortage and abundance of multi-core CPUs, raising that limit to
> let's say 4, would at least allow many people to run a Tor process per core on
> the same single IPv4 that they have (utilizing up to four cores, not just two).
>
> Considering that Tor is already somewhat multi-threaded (each process can use
> up to "120-130%" CPU), that might be just enough in most circumstances, since
> true 6-8-core CPUs are rare, and what's seen more often beyond 4 cores is
> either Intel HT or AMD's "light" core technologies.
>
> Of course the management (and memory) overhead of multiple processes is still
> there, so proper multi-core scaling is the ideal final goal.
>