<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-forward-container"><br>
<br>
-------- Forwarded Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
cellspacing="0">
<tbody>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject:
</th>
<td>Re: [tor-relays] Multi-core Support</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date: </th>
<td>Tue, 02 Jun 2015 11:55:31 -0400</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th>
<td>12xBTM <a class="moz-txt-link-rfc2396E" href="mailto:12xBTM@gmail.com"><12xBTM@gmail.com></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
<td>Roman Mamedov <a class="moz-txt-link-rfc2396E" href="mailto:rm@romanrm.net"><rm@romanrm.net></a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>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 <a class="moz-txt-link-rfc2396E" href="mailto:12xbtm@gmail.com"><12xbtm@gmail.com></a> 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.
>
</pre>
<br>
</div>
<br>
</body>
</html>