Hi all,
I've ran multiple Tor relays before but I have moved to a new server and
would like some advice.
My new server has 10Gb/s connection (I've observed it at 900MB/s to the
drives) with plenty of CPU and RAM to complement. I typically use
default configurations on my relays but I feel that to
Hey,
That's neat! Thanks for contributing.
How many CPU's / CPU cores does this new server have and does it use
AES-NI? How much RAM? Does it have multiple public IP addresses?
Currently it's complicated for a single Tor process to saturate a 10Gb/s
line, because it's not yet able to use all CPU
Suggest running multiple instances of the Tor daemon and
placing them in a single family. One daemon per physical core
up to perhaps eight. Only two daemons can be configured for
any two IP addresses so you need at least that many IPs, but
one-IP-per-daemon is ideal. When deciding how many daemo
On Aug 14, 2016 9:28 AM, "s7r" wrote:
>
> Currently it's complicated for a single Tor process to saturate a 10Gb/s
> line, because it's not yet able to use all CPU cores.
>
Out of curiosity, what is the maximum speed a single Tor instance can
achieve? Are there any plans for multi-core support?
_
Hey!
So the server is technically a VPS, it is a slice of a larger server
that is shared with 5 other people. Though I still have full root
access. So the whole 10gb/s is not just for me, but from my tests I can
at least get a few gigabit in real world speeds sustained.
CPU: 6x Xeon E5-2620v3 vCo
At 17:27 8/14/2016 +0300, s7r wrote:
>What I would do if I had multiple public IP
>addresses: make 4-5 virtual machines
Have to disagree here. VMs are extremely bad for
latency. Just go single physical machine and
create different user IDs to isolate the
daemons if you are concerned about someon
Hello,
In this case I suggest you run two separate Tor instances on the same IP
address (it is the maximum allowed). When I say 2 Tor instances I mean 2
separate data directories with separate identities.
If it's a VPS it's already a VM. It does not make sense to create a vm
inside a vm. You can
Hi i3,
Thanks for running relays! Agreed you will want to run multiple instances
to make the most of your host.
The Xeon E5-2620v3 does have AES-NI, which is good.
Other items to consider:
- On most linux/unix systems the ulimits will be set too low by default. On
debian-like linux, higher limi
> On 15 Aug 2016, at 06:54, Green Dream wrote:
>
> - You should install ntp make sure your clock is synced.
Alternately, run ntpdate via cron every few hours, to avoid running an
unnecessary network service.
(Recent security issues in ntp remain unpatched in some distributions.)
Tim
Tim Wils
On 08/14/16 20:48, teor wrote:
>
>> On 15 Aug 2016, at 06:54, Green Dream
>> wrote:
>>
>> - You should install ntp make sure your clock is synced.
>
> Alternately, run ntpdate via cron every few hours, to avoid running
> an unnecessary network service. (Recent security issues in ntp remain
> un
On Sun, 14 Aug 2016 20:57:13 -0400
George wrote:
> > Alternately, run ntpdate via cron every few hours, to avoid running
> > an unnecessary network service. (Recent security issues in ntp remain
> > unpatched in some distributions.)
>
> There's actually a technical problem with running ntpdate p
On 8/14/16, i3 wrote:
> My new server has 10Gb/s connection (I've observed it at 900MB/s to the drives
Depending on whether you meant MiB/s or MB/s,
you may find your network calculations off by 350Mbps,
which is a sizable tor relay's worth itself.
Standard use is decimal and bits for network "Mb
On Mon, 15 Aug 2016 02:35:49 -0400
grarpamp wrote:
> On 8/14/16, i3 wrote:
> > My new server has 10Gb/s connection (I've observed it at 900MB/s to the
> > drives
>
> Depending on whether you meant MiB/s or MB/s,
> you may find your network calculations off by 350Mbps,
To me these seem to be j
On 2016-08-15 at 08:52, Roman Mamedov wrote:
> https://en.wikipedia.org/wiki/Megabyte: "The megabyte is a multiple of the
> unit byte for digital information. Its recommended unit symbol is MB."
> MB/s is a long-accepted shorthand for Megabyte per second, and yes, Mb/s is
> megabit per second. But
On 8/15/16, Roman Mamedov wrote:
> To me these seem to be just two loosely related facts, the latter merely
> I don't see any "network calculations" being presented.
Was an fyi for the OP, who may or may not be doing calculations,
regardless of presentation to us.
> https://en.wikipedia.org/wiki
15 matches
Mail list logo
