Re: [tor-relays] Hardware sizing for physical exit node

[eff_03675549]

Hi,

my personnal experience with many many instances on never redundant 
hardware (I know diversity in hardware, locations...):


This is Exit specific:

1) never more than 4GB ram per core and never less than 2 cores per IP, 
let me explain:


a) most people will tell you that instances run per core, so why 2 cores?

+ because of DDOS and similar attacks, then the instance is jumping to 
the other core and is much a higher cost to kill than on their own (1 core).


This has the effect of putting the attack investment way above average 
and is going to save your instance from falling back months earlier than 
its current reputation level.


b) An IP will receive complaints and be banned (even when not from 
solely your ISP), not a VPS contract.
+ you want to avoid compromising other instances and this is why many 
IPs-max4GB is important: this spreads your hardware potential accross 
diversified IP affected by individual probabilities of being banned 
somewhere.


2) CPU work from tore is basic, RAM is the amplitude: you want a maximum 
of modern to medium-old CPUs threads,
save on your cpu choice (but study their known vulnerabilities) for an 
even number of heads, prefer cpus with most threads.



TO CONCLUDE:

64GB ram for 10Gbps is normally overkill :

10Gbps (octets) 24/7 is 3300 TeraB-Y-T-E-S / month, this one hardware cap.
I have never witnessed a conventional (relay) 1Gpbs-2BG-1thread tor 
instance outperforming 10MB-Y-T-E-S, this is kind of a Tor-cap.


This is inviting to never overkill with a 10Gbps+ connection less than 
100 x 10MB-Y-T-E-S (and this even when stipulating max bandwidth to some 
infinite number in your torrc).


My answer: with 10Gbps unlimited bandwidth, have 100 threads (50 to 100 
cores) at the cheapest CPU and 2GB to 4 GB per thread (more than 64GB in 
total).
My answer for virtualized instances :  when you do make the unsecured 
choice of polling your ram on KVM (or alternative) then the above works 
with 64GB ram. This is a bad idea.



This is real world experience and I understand that theory is suggesting 
very different perfomances

namely : what?!!! 10MB for 2GB ram?!!!.

yep.


Carlos.



On 7/10/24 12:32 AM, Osservatorio Nessuno via tor-relays wrote:

Hi everyone,
we are planning to get some hardware to run a physical Tor exit node, 
starting with a 1Gbps dedicated, unmetered uplink (10Gbps downlink). 
We will also route a /24 on it, so we will have large availability of 
addresses to run multiple instances. We have been running a few exit 
nodes so far, but never on our own hardware.


Which is the bandwith limit per core/Tore instance? Or what can we 
expect to be the bottleneck?


Due to some other requirements we need for some experiments (SFP 
ports, coreboot support, etc) we can mainly choose between these 2 CPUs:

Intel i5-1235U
Intel i7-1255U

The cost between the two models is significant enough in our case to 
pick the i7 only if it's really useful.


In both cases with 32GB of DDR5 RAM (we can max to 64 if needed, but 
is it?).


Should this allow us to saturate the uplink?

To summarize, with this bandwith, this hardware and a /24 how many Tor 
exit nodes should be ideal to run considering that each of them could 
have their own address?


Thanks!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


--
PGP updated every second week : please actualize our communication every time.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Hardware sizing for physical exit node

[mail--- via tor-relays]

Hi,

Imo mobile chips with mostly low-performance 'efficient cores' are a suboptimal 
fit for running Tor at scale. A couple of reasons:

- Performance between the different core types (efficient vs. performance) is 
very different. You would need to lock Tor processes to specific cores and 
accept that you can only run 2 fast relays (and 8 slow ones), or have 10 of 
them capped at the efficient core's performance profile (because the Tor 
processes would get swapped around all the time).
- These CPUs aren't build for sustained loads so their real world sustained 
clock speed is significantly lower than their turbo speed, hampering their 
performance (especially compared to benchmarks).

That being said, especially the 2 performance cores are quite decent and should 
be able to push some nice amount of Tor traffic (with some help from the 
efficient cores). My guess is that the i7 would not saturate a 1 Gb/s link 
(probably 600-650 Mb/s when utilizing all cores effectively) if your relays 
have the guard flag. Middle only relays would push more traffic. So with some 
quirks/workarounds, I think you could certainly make these CPUs work (but I 
still wouldn't recommend them).

Do you need SFP or SFP+? Both aren't a feature of the CPU (except for some 
embedded SoCs) and are generally easily/cheaply available. For example the 
Intel X520-DA2 and Mellanox ConnectX-3 are extremely affordable second hand or 
refurbished and both of the CPUs have enough PCI-e lanes to run them at full 
speed.

Regarding i5 vs i7: the i7 effectively only has a higher sustained clock speed 
and marginally better GPU (which is irrelevant for Tor) but otherwise is pretty 
much identical. If the difference would be small (i.e. ~20 euro/dollar) I would 
go for the i7 but otherwise I wouldn't bother. Your mileage may vary of course 
:-).

About RAM: Tor is (for the most part) single threaded so quite a few operators 
run one Tor process per physical core or per thread. In your case this would 
mean 10 or 12 Tor relays. Especially guard relays can go out of memory very 
easily nowadays because of all sorts of attacks, so I wouldn't recommend less 
than 4 GB of available RAM per relay (so 40-48 GB for Tor + X GB for 
OS/networking/routing/firewall/services/etc.). 90% of the time you don't need 
it, but when you do need it it makes sure Tor doesn't crash, your kernel 
doesn't panic and your server stays responsive (e.g. ssh) etc. You could also 
run less relays (or limit their bandwidth) and keep it at 32 GB of RAM, but 
then you would have a harder time to saturate the uplink.

Cheers,

tornth


Jul 10, 2024, 11:30 by tor-relays@lists.torproject.org:

> Hi everyone,
> we are planning to get some hardware to run a physical Tor exit node, 
> starting with a 1Gbps dedicated, unmetered uplink (10Gbps downlink). We will 
> also route a /24 on it, so we will have large availability of addresses to 
> run multiple instances. We have been running a few exit nodes so far, but 
> never on our own hardware.
>
> Which is the bandwith limit per core/Tore instance? Or what can we expect to 
> be the bottleneck?
>
> Due to some other requirements we need for some experiments (SFP ports, 
> coreboot support, etc) we can mainly choose between these 2 CPUs:
>  Intel i5-1235U
>  Intel i7-1255U
>
> The cost between the two models is significant enough in our case to pick the 
> i7 only if it's really useful.
>
> In both cases with 32GB of DDR5 RAM (we can max to 64 if needed, but is it?).
>
> Should this allow us to saturate the uplink?
>
> To summarize, with this bandwith, this hardware and a /24 how many Tor exit 
> nodes should be ideal to run considering that each of them could have their 
> own address?
>
> Thanks!
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Hardware sizing for physical exit node

[Toralf Förster via tor-relays]

On 7/10/24 00:32, Osservatorio Nessuno via tor-relays wrote:



In both cases with 32GB of DDR5 RAM (we can max to 64 if needed, but is
it?).


IMO 4 GiB RAM per tor process is needed, with 2 GiB I sometimes
experienced an OOM.

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Hardware sizing for physical exit node

[lists]

On Mittwoch, 10. Juli 2024 00:32:04 CEST Osservatorio Nessuno via tor-relays 
wrote:

> we are planning to get some hardware to run a physical Tor exit node,
> starting with a 1Gbps dedicated, unmetered uplink (10Gbps downlink). We
> will also route a /24 on it, so we will have large availability of
> addresses to run multiple instances. We have been running a few exit
> nodes so far, but never on our own hardware.

Your bottleneck is the 1G uplink.
For comparison, I have 2x Xeon E5-2680v2 10C/20T and 256Gb RAM
2x 10G nic (LACP bond) and I can not achieve 10G throughput with it.
As a rule of thumb, I would always count one instance per thread or core.
I have 40T and 40 tor exit instances.

F3Netze has specified the hardware in Contact info:
https://metrics.torproject.org/rs.html#search/185.220.100.

> Which is the bandwith limit per core/Tore instance? Or what can we
> expect to be the bottleneck?

That depends on the CPU clock speed. Fast Ryzen or Epyc's can do 50-70 MiB/s 
per core/instance.

> Due to some other requirements we need for some experiments (SFP ports,
> coreboot support, etc) we can mainly choose between these 2 CPUs:
>   Intel i5-1235U
>   Intel i7-1255U
> 
> The cost between the two models is significant enough in our case to
> pick the i7 only if it's really useful.
> 
> In both cases with 32GB of DDR5 RAM (we can max to 64 if needed, but is
> it?).
> 
> Should this allow us to saturate the uplink?

Guards need more resources than exits since the introduction of congestion-
control and because of DDoS I would use 64GB RAM for a guard.
With your IP space and 1G uplink, I would take the i5 with 32Gb, save the 
money and maybe add a second server later. Or if you build the hardware 
yourself, look for a used Epyc or Ryzen server. 16 or 32 core with high _base_ 
clock. Used server hardware from the data center is like new.

> To summarize, with this bandwith, this hardware and a /24 how many Tor
> exit nodes should be ideal to run considering that each of them could
> have their own address?

https://metrics.torproject.org/rs.html#search/185.220.101.
We are 5 relay orgs sharing a /24. Currently 5x 2x10G(or 25G)
With now 8 relays per IP, over 2000 instances can run in a /24 subnet. It 
would be nice if you share the subnet with 1-2 other relay operators.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Hardware sizing for physical exit node

[Osservatorio Nessuno via tor-relays]

Hi everyone,
we are planning to get some hardware to run a physical Tor exit node, 
starting with a 1Gbps dedicated, unmetered uplink (10Gbps downlink). We 
will also route a /24 on it, so we will have large availability of 
addresses to run multiple instances. We have been running a few exit 
nodes so far, but never on our own hardware.


Which is the bandwith limit per core/Tore instance? Or what can we 
expect to be the bottleneck?


Due to some other requirements we need for some experiments (SFP ports, 
coreboot support, etc) we can mainly choose between these 2 CPUs:

Intel i5-1235U
Intel i7-1255U

The cost between the two models is significant enough in our case to 
pick the i7 only if it's really useful.


In both cases with 32GB of DDR5 RAM (we can max to 64 if needed, but is 
it?).


Should this allow us to saturate the uplink?

To summarize, with this bandwith, this hardware and a /24 how many Tor 
exit nodes should be ideal to run considering that each of them could 
have their own address?


Thanks!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Hardware requirements for a fast Tor relay

[Elias via tor-relays]

-BEGIN PGP SIGNED MESSAGE-

Hash: SHA256

>Since this is virtualization, make sure that features such as AES

>acceleration are active.

Yes, I have tested that. Is active.

>The number of cores is not really relevant since Tor is not

>multi-threaded. The EPYC 7702 can boost up to 3.35 GHz, check that it

>reaches that under load.

It actually reaches the frequency under load.

Unfortunately, the one core is now fully under load.

My Relay moved 5TB today, with an average bandwidth of 500Mbit.

The average load according to HTOP is now just over 1.0, which is fine for a 
dual core.

However, one core is loaded to 100%. So far, there are no error messages and I 
achieve a stable 40MB/s with peaks of up to 50MB/s.

But my Relay is only a few days old. Advertised Bandwith is currently at just 
over 30 MiB, but that will change soon.

I'm afraid the CPU won't do much more, but with 500Mbit/s I'm among the fastest 
Relays at this hoster. Directly on page 1.

Let's see if I can tune a bit, otherwise I'll just let it run as long as no 
errors appear.

>Also since you have 2 cores, you can run two instances of Tor.

Yes, I know. However, the DirAuths then have more work to do because they have 
to add another Relay to the Consensus.

Everything has advantages and disadvantages. Let's see what I do.

>> I chose this server because the bandwith is unmetered and it's a

>> guaranteed 1GHz link.

>I assume you mean 1 Gbit/s.

Yes, that was a typo.

By the way, can someone explain to me how to reply directly to a reply in a 
thread without my reply just appearing at the bottom?

I'm new to this list and haven't quite figured it out yet. I hope you 
understand what I mean - I want my replies to be indented correctly. Thanks!

Have a great weekend, everyone!

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEElcZnZFMJSyKcTts0q6Mz3/Qy4d0FAmGO/j0ACgkQq6Mz3/Qy

4d395A/+NDRe7IhCbsmgWCUM2Li1XnoN4g3Z091T+U1QPQg7kCvibXXeiHhgs/jP

und/63N7FM3OmHi/WUPerK4qfk5lssRU0OPvyAApIzruCTBDj2TuCdpagsfNRQCU

QFE162q/cUvwRDyoNHVXxhSk8Bvtwj6Mxw4oE5p6yJFvBgSjT7uHGZgAgHobs/QH

zgCKsoEI3H0Wj8kYtxfP9xlhDe1XNidaGIXe5axFlcraw2/f7LXhG7BPJ2XaQHsp

CCPFOoLt3Ggpl3AFyIT/UYJ+2e/y+RJXSy71ptew0Xl3MQXv8j5avpo1zmDFXYqV

4SYbjzqmn/5t/O5QPprTBDVr2+SgkjNoFJWFTFK5R7jjqqGvs9fzbAXV6XGOKBeC

F6aRs/caQiJ57gAJmYdUW9dQubeIulR0yUlQlwXWWdAPEduLP3B8MxDtEuFOYHWL

h+C3I1tlPp+DFE3hfPARW1hX8DGBtA8pH6MKwn6onJh65mWv6f7pmU8LQHbuPPmw

w7o7qZHuXxhFSoxPRklISr0BjcLG94DHGWlD2UMyxpU/m3745+JGHhqlTJX+/aeN

HHWJ9FN1beI4YHfeUHBgicEx8pywtHK/l6vi5v9rrzko7nbYwG4SayrsgrpXqz6F

ifqCNzouxpjVs7MvuTDPIC62mNLED7Zop3tsMwdnyRZJc8Lm3Uo=

=Gm4l

-END PGP SIGNATURE-

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Hardware requirements for a fast Tor relay

[tor-operator--- via tor-relays]

Elias via tor-relays  wrote:

> This is actually not a "real" root server, it's a KVM server (of
> course). The CPU is an AMD EPYC 7702 with 2 dedicated cores per
> server@3,35GHz.

Since this is virtualization, make sure that features such as AES
acceleration are active.

The number of cores is not really relevant since Tor is not
multi-threaded. The EPYC 7702 can boost up to 3.35 GHz, check that it
reaches that under load.

Also since you have 2 cores, you can run two instances of Tor.

> I chose this server because the bandwith is unmetered and it's a
> guaranteed 1GHz link.

I assume you mean 1 Gbit/s.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Hardware requirements for a fast Tor relay

[Elias via tor-relays]

-BEGIN PGP SIGNED MESSAGE-

Hash: SHA256

Thank you for your suggestions, Gary.

This is actually not a "real" root server, it's a KVM server (of course). The 
CPU is an AMD EPYC 7702 with 2 dedicated cores per server@3,35GHz. I chose this 
server because the bandwith is unmetered and it's a guaranteed 1GHz link. I 
don't think I will ever be able to relay 125MB/s, but I will try my best. If I 
can only reach ~50MB/s before the CPU starts to grumble I will set up a second 
Tor process and a second relay.

I tuned my relay a bit today, using some of the tips from this conversation:

https://lists.torproject.org/pipermail/tor-relays/2010-August/000164.html

It's not really up to date, but still useful to some extent.

Unfortunately I had to restart the Tor process, but my relay was already 
measured a few times and reaches spikes of 30MB/s. CPU usage is no issue at all 
yet, there is room for more. I can wait before I get the guard flag, this is 
not a race...

Thanks again for your help.

All the best.

PGP-Fingerorint: 95C6676453094B229C4EDB34ABA333DFF432E1DD

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEElcZnZFMJSyKcTts0q6Mz3/Qy4d0FAmGMbCAACgkQq6Mz3/Qy

4d2bpBAAmQIQ6wvjeBhdL4DxPdL9qlxIqbjPMxpPQWWCqSa3x/t+V3mcEzl/Srz7

5hUVwmYwMprtVA9Zf/MDPCElqbs5MpDrHkJE/rGhfEc6ld/Xu62LLVS7US+/ocTb

RCLW1WG8pAQymR9avbyDqTqqTBOinIGlxwmCLXAldEllsxfVnKd4nFzxxEv/Ms/4

JrWvnOjJde46CCFchmjEfUGWVgquU9lsjpHbqVz/+ErUKVAd57BmPNpteiXed8xi

RuM6BqB5/blL+CmdVISprisaIPIhqlCW5UEkuNPm5ijlrKrBYTSn4/b8HnMdg5UE

ynAkzR5dkxyYee+uI84mgIfFNUzaVBpBq2W5obPqGiocoWQKgT70zVPxzLuguyoG

U/Mzxikq4K86aorimSad207BEIVkey76s6jqqgKKI7UoTIYUTmc1xsA1tcgi44Me

MelT5gEZ/fcesfPpYB/gkIyOIE+ADuCfnvOqDWAOvfnX9q6U9ek8+aHYSXGIdf9M

oKjAKkO8Y/BWBsEHlnyBIrfE48/WtSNlQRj9oKSzyFtQs8wDhgoe3mgcvyHnPTOu

Tq7UJUGV3L1LHOW6iEZTMKUsD9t1/NpGLpnTgTXne6bYzyJYL4D5w6IX30EaeaPw

387TB7cTj8Vaaw2bTiM7NlfAEdWqxt2v0qcgzFtTSIhnHLGtnQo=

=tlZd

-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Hardware requirements for a fast Tor relay

[Gary C. New via tor-relays]

The following are some of the more important config options that I use for such 
a small middle relay:




# Tor: A non-exit relay should be able to handle 7000 concurrent connections    
                                                              



ulimit -n 65535




DirCache 0                                              

ExitRelay 0                     




# Note: The default MaxMeminQueues is 3/4 (i.e., 192MB) of Total System Memory 
(i.e., 256MB)                   

# Uncomment the following line to limit Tor to use less System Memory (i.e., 
128MB)

MaxMemInQueues 192 MB               

                                        

Log notice file /tmp/torlog                             

Log notice syslog

RunAsDaemon 1                                           

DataDirectory /tmp/tor/torrc.d/.tordb                   

AvoidDiskWrites 1

—
This Message Originated by the Sun.
iBigBlue 63W Solar Array (~12 Hour Charge)
+ 2 x Charmast 26800mAh Power Banks
= iPhone XS Max 512GB (~2 Weeks Charged) 

On Wednesday, November 10, 2021, 2:36:13 AM MST, failing.flyaway443--- via 
tor-relays  wrote:  
 
 Hi Gary,
thank you for your response.
I think I just worry too much.
I watched my relay all the time today, I had bandwidth usage of 30MB/s at times 
and HTOP showed me a Load average of 0.29/0.29/0.30. I know that this is 
totally fine for a dual core. 
The relay is up and running for 3 days and 8 hours now and I already moved 
~700GB in each direction (upload/download). I was just concerned because the 
VPS started crashing after 2 weeks solid uptime, but I should have set stricter 
bandwith limits. 
You can't really compare a VM with a root server, I don't think this will 
happen again. 
It's ok for me to invest a little more and have a fast and stable relay this 
way. The traffic was capped with the VPS plan, this was obviously a big 
disadvantage, now I can use as much traffic as I want with a 2,5Gbit link 
(1Gbit guaranteed).
For your info, the most important lines of my config:
SocksPort 0
Log notice file /var/log...
Log debug file /var/log...
ORPort 443
RelayBandwithRate 1000Mbit
RelayBandwithBurst 1000Mbit
Exit policy reject *:*
ContactInfo & Nickname set, of course... ;)

Is there anything I should change?

Thanks for your help!

Best Regards...


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
  ___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Hardware requirements for a fast Tor relay

[Elias via tor-relays]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm sorry that I now spam the mailing list, but I made a mistake.
I'm of course NOT logging at debug level, it's just one logfile (notices.log). 
I logged debug when I was running the relay on the VPS because I wanted to know 
why it crashed all the time, but all that happened was that my 20TB SSD was 
maxed out within two hours and I had to reboot to get rid of the old logfiles.
My bad, please don't think I write a debug log, that's completely pointless. 
Why would I. I rented a pretty expensive root server because I think Tor is 
really important and I want to relay as much traffic as possible, not to log 
debug messages.
This was obviously not correct, but the rest of my torrc looks as described 
above.
By the way, my relay has now around 4000 incoming and 4000 outgoing connections 
and a throughput of almost 1TB/day, and the load averages are still below .40. 
Everything looks good. :)
Have a nice day, everyone!

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEElcZnZFMJSyKcTts0q6Mz3/Qy4d0FAmGLxa0ACgkQq6Mz3/Qy
4d1vJhAArWytI9hG6iGIvVzUP6lOgLMCEVfn4KBiFzq0iGqr2ex+utWIt8gek3SX
Bm9McRbicgDUSzbnrHJrPzKxrpYvvtABbApyDZDSOEwgSXeaUcE2J8jhk20fOA6u
tLFf7S+ON88KW8HkwNIkqSFmRifp3dZEBOapFZnBfgREwu19qxg1iyYZfJHDIMd6
4vWzI5oo2D1iFTyCDZllduqEURZNgZRfwtNk8ydfOje9X0QMkHgzy4fECCNgcYdY
to+1BbYxY2lT34+1aLoRnnyA2yLykYI2ivRNx+IyD9X/QCKq+3sV+xjRvyOH39r7
Tmvg8NTNuZCiEwi9JCIJlRynrFk3HgUTbCT87iK8PGMTG6TimnBvFKUfKQMwIicD
1YrLQ30hSjTnetRbyLT0B7gd+h+CkDg6ssi0j6eKV0urP6PTipnr19OJeBZ3kZbw
j+a3qipxy3mNIp9dW9d+ZBzhV+jtrDUMKUpjqHUkUEEdNH060TSMyYMBwCf7/dgH
Ft8FWgTcLtX9dohx/CAHfQ+8rsa/wYEuLnXgc3AXibof9VZaTMKz5iDkhUwOnCoA
0528RNKLH+Rf4CoMOCycjqW0k1svPX9oAXoOgX0GQz/1DnocA4DEs+wVPJmr6dR+
mcHwDiKlOd5ksARl+fivmHurUE+ULzhI8l+Cdhr+Wi7NzVzuZ5U=
=s8hY
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Hardware requirements for a fast Tor relay

[failing.flyaway443--- via tor-relays]

I just read this research paper, maybe it's worth thinking about some kind of 
implementation of this approach some time in the future.
It's an interesting read anyway.
uwspace.uwaterloo.ca/bitstream/handle/10012/16108/Engler_Steven.pdf

Regards
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Hardware requirements for a fast Tor relay

[failing.flyaway443--- via tor-relays]

Hi Gary,
thank you for your response.
I think I just worry too much.
I watched my relay all the time today, I had bandwidth usage of 30MB/s at times 
and HTOP showed me a Load average of 0.29/0.29/0.30. I know that this is 
totally fine for a dual core.
The relay is up and running for 3 days and 8 hours now and I already moved 
~700GB in each direction (upload/download). I was just concerned because the 
VPS started crashing after 2 weeks solid uptime, but I should have set stricter 
bandwith limits.
You can't really compare a VM with a root server, I don't think this will 
happen again.
It's ok for me to invest a little more and have a fast and stable relay this 
way. The traffic was capped with the VPS plan, this was obviously a big 
disadvantage, now I can use as much traffic as I want with a 2,5Gbit link 
(1Gbit guaranteed).
For your info, the most important lines of my config:
SocksPort 0
Log notice file /var/log...
Log debug file /var/log...
ORPort 443
RelayBandwithRate 1000Mbit
RelayBandwithBurst 1000Mbit
Exit policy reject *:*
ContactInfo & Nickname set, of course... ;)

Is there anything I should change?

Thanks for your help!

Best Regards...
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Hardware requirements for a fast Tor relay

[Gary C. New via tor-relays]

It's surprising that you're running into CPU issues. It's typically RAM that is 
exhausted first.




I have 5 x Dual Core 256MB Tor Relay Nodes loadbalanced as a Single Middle 
Relay that never have CPU issues. It's always a matter of running out of RAM 
for me. The loadbalanced Tor Relay maintains between 6K-8K circuits and between 
100-200GB of Tor traffic per day.




Presently, 2 of the Tor Nodes are down, but you can see that for those Tor 
Nodes that are up my CPU load is low and memory is approaching the 32MB cutoff 
that I've configured.




# stat-tor-nodes      

Living_Room-C293                                        

 12:52:23 up 1 day, 12:42,  load average: 0.80, 0.54, 0.46                      
                                 

Data_Center-D448                                        

 12:52:24 up 1 day, 12:42,  load average: 0.69, 0.69, 0.71                      
                                 

Office-3C73                                             

 12:52:24 up 1 day, 12:41,  load average: 2.58, 2.84, 3.75                      
                                 

Garage-AE61                                             

 12:52:25 up 1 day, 12:42,  load average: 0.00, 0.07, 0.10                      
                                 

Wiring_Closet-5610                                      

 12:52:25 up 1 day, 12:41,  load average: 0.24, 0.33, 0.41                      
                                 

Living_Room-C293                                        


MemFree:          110696 kB                             

Data_Center-D448                                        

MemFree:           42744 kB                             

Office-3C73                                             

MemFree:           86792 kB                             

Garage-AE61                                             

MemFree:          193384 kB                             

Wiring_Closet-5610                                      

MemFree:           38684 kB                             

Living_Room-C293                                        


2000                                                    

Data_Center-D448                                        

2710                                                    

Office-3C73                                             

0                                                       

Garage-AE61                                             

0                                                       

Wiring_Closet-5610                                      

1854




It might help to provide your torrc config.

—
This Message Originated by the Sun.
iBigBlue 63W Solar Array (~12 Hour Charge)
+ 2 x Charmast 26800mAh Power Banks
= iPhone XS Max 512GB (~2 Weeks Charged) 

On Tuesday, November 9, 2021, 8:48:09 AM PST, failing.flyaway443--- via 
tor-relays  wrote:  
 
 Hi everyone,
about two weeks ago, I signed up for a VPS with a cloud provider and set up a 
Tor relay. I installed Debian 11 Bullseye, secured it, and then set up Tor 
0.4.6.8 and started the relay.
The VPS had the following specs: 1vCore, 2GB RAM, 40TB traffic per month on a 
1Gbit/s link. I throttled the traffic accordingly so that the monthly limit of 
40TB would not be exceeded. Nevertheless, the CPU load was extreme, the server 
was running at full capacity and crashed several times.
Since I want to help the Tor network with a fast relay I now signed up for a 
root server  which has the following specs: Dual core CPU, 8GB ECC RAM, 2,5Gbit 
link, 1Gbit guaranteed, unlimited traffic.
I set this thing up with Debian 11 Bullseye again and Tor 0.4.6.8. Since my 
bandwith gets throttled when I use more than a certain amount of traffic/month 
and at the same time (!) on average more than a certain amount of bandwith for 
more than one hour, I set the MaxBandwith to 1000Mbit/sec (equals 125MB/sec).
This relay is up and running for a few days now, and I already have around 4000 
incoming and outgoing connections. My bandwith is not fully used yet, but 
sometimes I see spikes of 20MB/s. What concerns me is that the CPU load again 
is sometimes 40-50% on both cores, even though this relay is not fully used 
yet. 
Can somebody tell me if it is even possible to run such a fast relay on this 
hardware?
Should I set a more restrictive bandwith throttle myself, or go for a quad core 
CPU?
I don't think I will ever run out of RAM this time, since I have 8GB.Thank you 
for your advice! All the best!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
  ___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Hardware requirements for a fast Tor relay

[failing.flyaway443--- via tor-relays]

Hi everyone,
about two weeks ago, I signed up for a VPS with a cloud provider and set up a 
Tor relay. I installed Debian 11 Bullseye, secured it, and then set up Tor 
0.4.6.8 and started the relay.
The VPS had the following specs: 1vCore, 2GB RAM, 40TB traffic per month on a 
1Gbit/s link. I throttled the traffic accordingly so that the monthly limit of 
40TB would not be exceeded. Nevertheless, the CPU load was extreme, the server 
was running at full capacity and crashed several times.
Since I want to help the Tor network with a fast relay I now signed up for a 
root server which has the following specs: Dual core CPU, 8GB ECC RAM, 2,5Gbit 
link, 1Gbit guaranteed, unlimited traffic.
I set this thing up with Debian 11 Bullseye again and Tor 0.4.6.8. Since my 
bandwith gets throttled when I use more than a certain amount of traffic/month 
and at the same time (!) on average more than a certain amount of bandwith for 
more than one hour, I set the MaxBandwith to 1000Mbit/sec (equals 125MB/sec).
This relay is up and running for a few days now, and I already have around 4000 
incoming and outgoing connections. My bandwith is not fully used yet, but 
sometimes I see spikes of 20MB/s. What concerns me is that the CPU load again 
is sometimes 40-50% on both cores, even though this relay is not fully used yet.
Can somebody tell me if it is even possible to run such a fast relay on this 
hardware?
Should I set a more restrictive bandwith throttle myself, or go for a quad core 
CPU?
I don't think I will ever run out of RAM this time, since I have 8GB.
Thank you for your advice! All the best!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Hardware specs for a high-bandwidth Tor exit?

[NOC]

Hi Christian,

a AMD EPYC 7642 should be able to saturate that 20 GBit/s connection 
fine, Mainboard depends on what you prefer. Supermicro, HP and so on 
have all Mainboards for that CPU, so choose the one you prefer.


On 06.11.2019 00:15, Christian Pietsch wrote:

Dear Tor friends,

the NGO I am volunteering for (Digitalcourage e.V.) has been running
modest Tor exits for many years. Now we finally have the opportunity
to run a high-bandwidth exit relay because we found a data center with
a nice internet connection (20 Gbit/s) we may use.

My question is: What kind of hardware should we buy to utilize this
bandwith? I am told that we need an SFP+ networking card to connect to
the fibre optics cable, but what CPU and mainboard would you recommend
nowadays? It should fit into a 1 height unit 19" enclosure.

If you prefer to tell me in person: I will attend the Tor meetup in
Brussels on Friday
and the subsequent Freedom Not Fear event.

Cheers,
Christian


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Hardware specs for a high-bandwidth Tor exit?

[ylms]

Hello Christian,
please also report back with the information you found out. I am also
pretty interested, running Tor Exits for various German NGOs this really
is a topic I am interested in.

Currently the fastests Exit I operate in Germany is "only" doing a
little more than 30MiB/s I think. But it only has 1GBit/s connection and
I never bothered about this, as I fear the hoster will terminate the
contract if I use all bandwidth.

I guess I would

So however, let us know what you found out.

And make sure, if possible, to come to 36c3 meetup.
Thanks
yl




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Hardware specs for a high-bandwidth Tor exit?

[Christian Pietsch]

Dear Tor friends,

the NGO I am volunteering for (Digitalcourage e.V.) has been running
modest Tor exits for many years. Now we finally have the opportunity
to run a high-bandwidth exit relay because we found a data center with
a nice internet connection (20 Gbit/s) we may use.

My question is: What kind of hardware should we buy to utilize this
bandwith? I am told that we need an SFP+ networking card to connect to
the fibre optics cable, but what CPU and mainboard would you recommend
nowadays? It should fit into a 1 height unit 19" enclosure.

If you prefer to tell me in person: I will attend the Tor meetup in
Brussels on Friday 
and the subsequent Freedom Not Fear event .

Cheers,
Christian

-- 
Christian Pietsch | volunteering for Digitalcourage e.V., Germany
Digitalcourage e.V.: https://digitalcourage.de/
BigBrotherAwards Germany: https://bigbrotherawards.de/
Betting living without Google: https://pad.foebud.org/google-alternatives


signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Hardware specs for Tor Relay

[Nusenu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

> I figured that the CPU is so busy because the vserver doesn't have 
> AES-NI, which I confirmed by some command I run (forgot the
> command).
> 
> So I thought I might wanna move that relay to another server, maybe
> at the same hoster to get higher data transfer.

You might want to consider running more than one tor instance to use
more of your bandwidth.
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJVFHbdAAoJEFv7XvVCELh0cJMP/jcsFVkcw20iRsRYvN0bGbYi
QBLqiK0gizRCIScMT1eX/d9qot9C1p6PnJSScRsoy7kjp3OyKKxOga8bsFMpfFyl
eoPFkDBvnoXfP5dlUvr70uUs9JUK3WOfy3rjIo61VvDLcp09ZM5VupeIanxru66V
b9r1LB4J5VbpNSHq0Zq/94kovbAqN4LsZ3ORMviA9IihlUoJVEiMkGftd9ApuE45
ZSXv/4quCSSEa1sYlLCrhSRLaAteuqPH57Q+w9syAQYTUCV4qgkUf113713gZSYL
VSRTMuQhWrWmXxqRN6H/At248NgcBaf1qvzcaETBgsLCZY5FzqAOGWiFbYGSJfDR
8wevEf9lxbGLeHVOiiVzWBliSRw2RsSQ9/OeeroSjAKPO0fMnK29J4UGnvm6Cfp2
msSyBKSX+AMQUeNRGwKuOx+1W7IPqJuRIcQdZ/Fjhtgs5BwCVrtw4oDYd6vG1avP
FE4WKx1DFLVsqVkrFJ2UkNlhzCnSsWbVvzkLaqzckSLmA2zEw/Cj5jInYULvGO0f
0BDt6CtO+Ifjdjw/UHfMa/JiKZchyu5OsDDvti+h1cy6j5X1LN+aECWsq2SQcpbX
JkCuTiHzDr7MTstf5oHU2Qmiu5QShesvjDW5wC/XfiKGNaBcWsO2/ycJbJ59eOqm
6kQGIN2JGbwIaY7X1XJr
=V3LX
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Hardware specs for Tor Relay

[Sebastian Urbach]

On March 26, 2015 8:59:45 PM yl  wrote:

Hi,


Hello,
I clicked myself a cheap vserver 20 days ago and it runs Tor since then.
I mainly did this to play a bit with the relay, try around and so. I
took over another relay a while ago, an exit, I don't want to try around
on that.

It runs well, I got about 4,4 TB data up AND down since then, I have it
running with 20-40Mb/s on a 100Mb/s connection (according to the hoster
100Mb/s), it runs as a non exit. CPU load it pretty high all the time
according to arm it's about 80-100%, but with htop I can see that only
one core of the CPU is busy, the others are not.

I figured that the CPU is so busy because the vserver doesn't have
AES-NI, which I confirmed by some command I run (forgot the command).


Did you ask them if you can get it ? I had a VPS a while ago and they said 
"we disabled that for compatibility reasons" but if you want it we will 
turn it on. And they did it for free :-)




So I thought I might wanna move that relay to another server, maybe at
the same hoster to get higher data transfer.

What hardware specs do you have and is my assumption correct with the
AES-NI being one part of the bottleneck?


It is the no. 1 bottleneck from my experience. I still hope that we are 
going to see the crypto-multithreading feature at some point in the future.


--
Sincerely yours / Sincères salutations / M.f.G.

Sebastian Urbach

-
Religion is fundamentally opposed to
everything I hold in veneration - courage,
clear thinking, honesty, fairness, and,
above all, love of the truth.
-
Henry Louis Mencken (1880 - 1956),
American journalist, essayist, magazine
editor, satirist and critic.


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Hardware specs for Tor Relay

[yl]

Hello,
I clicked myself a cheap vserver 20 days ago and it runs Tor since then.
I mainly did this to play a bit with the relay, try around and so. I
took over another relay a while ago, an exit, I don't want to try around
on that.

It runs well, I got about 4,4 TB data up AND down since then, I have it
running with 20-40Mb/s on a 100Mb/s connection (according to the hoster
100Mb/s), it runs as a non exit. CPU load it pretty high all the time
according to arm it's about 80-100%, but with htop I can see that only
one core of the CPU is busy, the others are not.

I figured that the CPU is so busy because the vserver doesn't have
AES-NI, which I confirmed by some command I run (forgot the command).

So I thought I might wanna move that relay to another server, maybe at
the same hoster to get higher data transfer.

What hardware specs do you have and is my assumption correct with the
AES-NI being one part of the bottleneck?

Thanks
yl
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware accelerated crypto

[Gordon Morehouse]

Happily, it DOES appear that there may be some hope for the Allwinner A20 based 
Cubieboard 2 (I haven't checked for the original Cubieboard yet):

"The Security System (SS) is one encrypt/ decrypt function accelerator that is 
suitable for a variety of
applications. It supports both encryption and decryption. Several modes are 
supported by the SS
module.

It features:

AES, DES, 3DES, SHA-1, MD5 are supported by this system
ECB, CBC, CNT modes for AES/DES/3DES
128-bit, 192-bit and 256-bit key size for AES
160-bit hardware PRNG with 192-bit seed
32-word RX FIFO and 32-word TX FIFO for high speed application
Support CPU mode and DMA mode
Interrupt support"

http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf

So, it may be a little help, anyway.

The Cubieboard 2 is great for small Tor relays - it'd definitely be more 
capable than a Raspberry Pi model B as it has double the RAM and 2 more 
powerful cores with ARMv7 instead of ARMv6.

It's also almost double the price (for considerably more than double the 
computer), but I don't expect that to last long.

Best,
-Gordon M.

On Tue, 01 Oct 2013 19:02:37 -0700, Gordon Morehouse  
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> I'm interested if there are any hardware accelerators in either the
> Raspberry Pi (which needs all the help it can get) or the Cubieboard 2
> (A20-based).
> 
> Best,
> - -Gordon M.
> 
> 
> Joshua Datko:
> > I was looking into this for the BeagleBone black [1], which has 
> > on-chip accelerators for AES, SHA (1 I think), and md5.  The TI 
> > processor also has a HWRNG.  My belief was that by using the
> > cryptodev kernel module [2] I could get this working, but I ran in
> > some issues building the kernel and then I was caught up in other
> > things.
> > 
> > I'm not sure if my approach was flawed or what, but maybe it helps
> > someone here.
> > 
> > Josh
> > 
> > [1] http://datko.net/2013/09/22/quest_bbb_crypto/ [2]
> > http://cryptodev-linux.org/
> > 
> > On Tue, Oct 1, 2013 at 2:35 PM, jason  wrote: I
> > would love to do all this actually but I never managed to get the
> > hw accelerated crypto (ssl/tls) bits working to experiment with.
> > I'd be up for restarting this if I knew I could consult with one or
> > two others who had a genuine interest in this. -Jason
> > 
> > On 10/01/2013 08:26 PM, Jeroen Massar wrote:
>  On 2013-10-01 21:20, Andy Isaacson wrote:
> > On Tue, Oct 01, 2013 at 06:45:52PM +, jason wrote:
> >> I'm not sure why I missed this first post but I'm very 
> >> interested in working on this project with whomever is 
> >> interested. I  bought a pogoplug v2 specifically to test
> >> it's usefulness as a tor exit or relay.
> > 
> > First step is, run "openssl speed rsa" and post the output
> > to the list. While you're at it you may as well post the
> > AES and SHA results as well. Heck, just run the whole
> > "openssl speed" test (should take less than 20 minutes) and
> > post the whole thing. :)
> > 
> > Also details on what CPU/RAM it has, and information about
> > the kernel and OpenSSL package you are testing, would be
> > useful. "dmesg" output and the contents of /proc/cpuinfo
> > may be helpful.
>  
>  Maybe a good idea to put the output in the wiki somewhere?
>  
>  Greets, Jeroen
>  
>  ___ tor-relays
>  mailing list tor-relays@lists.torproject.org 
>  https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> >
>  
> >> ___ tor-relays
> >> mailing list tor-relays@lists.torproject.org 
> >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> > ___ tor-relays mailing
> > list tor-relays@lists.torproject.org 
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> > 
> 
> - -- 
> Sent from my thing that sends email.
> -BEGIN PGP SIGNATURE-
> 
> iQEcBAEBCgAGBQJSS366AAoJED/jpRoe7/ujyREIAKb2xTXWR8xLdVpj2K8Dub9W
> jSuMtWycMgSW5nkJAOCwA+uJuX47/v7tzejNut1E76oRaAHwEn1fufiWGdT+Dbju
> f4BycdI5Pl3NTRuYcFBas32+lbFeyw+gLClczUjfE+fe/pmHiaXAXra6Alai40z8
> 77B/xGQwrpVyla4S8JHP4CY/p6FHuI5JDs+ghvVESUEK2DHJdNt5R2oLSBy4ZNQw
> BTzAf6qvflFUWhpWOkIkzIzo0c5FsJ/nYiVWpWyAjdV1NgufPdZ8ZKIoNx92iJBP
> aD1G7h9fQh3E2AU/6VHPvPdekQ5NPzehXtH8ywNFMw16oFbXkZ6/eUYUpJ50YZ8=
> =3Yig
> -END PGP SIGNATURE-
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware accelerated crypto

[Lukas Erlacher]

> The RasPi is nice but it's also not terribly powerful.  It definitely
> has its limits.  For example, I found out the hard way last weekend
> that trying to run an Etherpad-Lite on a RasPi is a great way to run
> one into the ground...

I have a RasPi Model B Rev 2 running etherpad-lite and a Tor-Relay.
Slow as shit, but it works. :-)
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware accelerated crypto

[The Doctor]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/01/2013 10:02 PM, Gordon Morehouse wrote:
> I'm interested if there are any hardware accelerators in either
> the Raspberry Pi (which needs all the help it can get) or the
> Cubieboard 2 (A20-based).

To the best of my knowledge, no.

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=7&t=2723

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=2&t=659

The RasPi is nice but it's also not terribly powerful.  It definitely
has its limits.  For example, I found out the hard way last weekend
that trying to run an Etherpad-Lite on a RasPi is a great way to run
one into the ground...

- -- 
The Doctor [412/724/301/703] [ZS]
Developer, Project Byzantium: http://project-byzantium.org/

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1
WWW: https://drwho.virtadpt.net/

Meeble!  Meeble meeble meeble!

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJMVucACgkQO9j/K4B7F8HS5QCg4l1g+ZO9zwUkYt6AAAYzwn+J
STwAoNijC841qjr7Toqfo2Zyf/edcmQz
=aaLU
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware accelerated crypto

[jason]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The pi doesn't have any as I'm aware of, I was looking into any and
all small boards that posses the marvell kirkwood chipset which is
supported by cryptodev module which openssl can be compiled to utilize.
The cheapest one seems to be the v2 pogoplug, which can be had for as
cheap as $20 USD off amazon.

here's some good info:
http://www.altechnative.net/2011/05/22/hardware-accelerated-ssl-on-marvell-kirkwood-arm-using-openssl-on-fedora/


Here's a brief overview of what I've tried to get working on my debian
squeeze pogoplug. http://forum.doozan.com/read.php?2,9619

Here's a good listing of common plug boards and which processors they
contain, including the pi: http://archlinuxarm.org/platforms

Perhaps if enough are interested we could form a small group to work
on this again. mail me directly if interested.

The output from the pogo 'openssl speed rsa' is as follows (keep in
mind this is WITHOUT cryptodev support enabled). If someone points me
to the appropriate place on the wiki I'll be happy to fill in the
required info.

Doing 512 bit private rsa's for 10s: 3906 512 bit private RSA's in 9.86s
Doing 512 bit public rsa's for 10s: 43400 512 bit public RSA's in
9.84s Doing 1024 bit private rsa's for 10s: 786 1024 bit private RSA's
in 9.87s
Doing 1024 bit public rsa's for 10s: 15983 1024 bit public RSA's in 9.86s
Doing 2048 bit private rsa's for 10s: 136 2048 bit private RSA's in 9.93s
Doing 2048 bit public rsa's for 10s: 5032 2048 bit public RSA's in 9.86s
Doing 4096 bit private rsa's for 10s: 22 4096 bit private RSA's in 10.32s
Doing 4096 bit public rsa's for 10s: 1479 4096 bit public RSA's in 9.85s
OpenSSL 1.0.1c 10 May 2012
built on: Sun Jul 29 13:43:04 UTC 2012
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial)
blowfish(ptr)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS
- -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2
- -fstack-protector --param=ssp-buffer-size=4 -Wformat
- -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro
- -Wa,--noexecstack -Wall
  signverifysign/s verify/s
rsa  512 bits 0.002524s 0.000227s396.1   4410.6
rsa 1024 bits 0.012557s 0.000617s 79.6   1621.0
rsa 2048 bits 0.073015s 0.001959s 13.7510.3
rsa 4096 bits 0.469091s 0.006660s  2.1150.2

- -J

On 10/02/2013 02:02 AM, Gordon Morehouse wrote:
> I'm interested if there are any hardware accelerators in either
> the Raspberry Pi (which needs all the help it can get) or the
> Cubieboard 2 (A20-based).
> 
> Best, -Gordon M.
> 
> 
> Joshua Datko:
>> I was looking into this for the BeagleBone black [1], which has 
>> on-chip accelerators for AES, SHA (1 I think), and md5.  The TI 
>> processor also has a HWRNG.  My belief was that by using the 
>> cryptodev kernel module [2] I could get this working, but I ran
>> in some issues building the kernel and then I was caught up in
>> other things.
> 
>> I'm not sure if my approach was flawed or what, but maybe it
>> helps someone here.
> 
>> Josh
> 
>> [1] http://datko.net/2013/09/22/quest_bbb_crypto/ [2] 
>> http://cryptodev-linux.org/
> 
>> On Tue, Oct 1, 2013 at 2:35 PM, jason  wrote:
>> I would love to do all this actually but I never managed to get
>> the hw accelerated crypto (ssl/tls) bits working to experiment
>> with. I'd be up for restarting this if I knew I could consult
>> with one or two others who had a genuine interest in this.
>> -Jason
> 
>> On 10/01/2013 08:26 PM, Jeroen Massar wrote:
> On 2013-10-01 21:20, Andy Isaacson wrote:
>> On Tue, Oct 01, 2013 at 06:45:52PM +, jason wrote:
>>> I'm not sure why I missed this first post but I'm very 
>>> interested in working on this project with whomever is 
>>> interested. I  bought a pogoplug v2 specifically to
>>> test it's usefulness as a tor exit or relay.
>> 
>> First step is, run "openssl speed rsa" and post the
>> output to the list. While you're at it you may as well
>> post the AES and SHA results as well. Heck, just run the
>> whole "openssl speed" test (should take less than 20
>> minutes) and post the whole thing. :)
>> 
>> Also details on what CPU/RAM it has, and information
>> about the kernel and OpenSSL package you are testing,
>> would be useful. "dmesg" output and the contents of
>> /proc/cpuinfo may be helpful.
> 
> Maybe a good idea to put the output in the wiki somewhere?
> 
> Greets, Jeroen
> 
> ___ tor-relays 
> mailing list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
> 
> 
>>> ___ tor-relays 
>>> mailing list tor-relays@lists.torproject.org 
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>>> 
___ tor-relays mailing
>> list tor-relays@lis

Re: [tor-relays] hardware accelerated crypto

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I'm interested if there are any hardware accelerators in either the
Raspberry Pi (which needs all the help it can get) or the Cubieboard 2
(A20-based).

Best,
- -Gordon M.


Joshua Datko:
> I was looking into this for the BeagleBone black [1], which has 
> on-chip accelerators for AES, SHA (1 I think), and md5.  The TI 
> processor also has a HWRNG.  My belief was that by using the
> cryptodev kernel module [2] I could get this working, but I ran in
> some issues building the kernel and then I was caught up in other
> things.
> 
> I'm not sure if my approach was flawed or what, but maybe it helps
> someone here.
> 
> Josh
> 
> [1] http://datko.net/2013/09/22/quest_bbb_crypto/ [2]
> http://cryptodev-linux.org/
> 
> On Tue, Oct 1, 2013 at 2:35 PM, jason  wrote: I
> would love to do all this actually but I never managed to get the
> hw accelerated crypto (ssl/tls) bits working to experiment with.
> I'd be up for restarting this if I knew I could consult with one or
> two others who had a genuine interest in this. -Jason
> 
> On 10/01/2013 08:26 PM, Jeroen Massar wrote:
 On 2013-10-01 21:20, Andy Isaacson wrote:
> On Tue, Oct 01, 2013 at 06:45:52PM +, jason wrote:
>> I'm not sure why I missed this first post but I'm very 
>> interested in working on this project with whomever is 
>> interested. I  bought a pogoplug v2 specifically to test
>> it's usefulness as a tor exit or relay.
> 
> First step is, run "openssl speed rsa" and post the output
> to the list. While you're at it you may as well post the
> AES and SHA results as well. Heck, just run the whole
> "openssl speed" test (should take less than 20 minutes) and
> post the whole thing. :)
> 
> Also details on what CPU/RAM it has, and information about
> the kernel and OpenSSL package you are testing, would be
> useful. "dmesg" output and the contents of /proc/cpuinfo
> may be helpful.
 
 Maybe a good idea to put the output in the wiki somewhere?
 
 Greets, Jeroen
 
 ___ tor-relays
 mailing list tor-relays@lists.torproject.org 
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

>
 
>> ___ tor-relays
>> mailing list tor-relays@lists.torproject.org 
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

- -- 
Sent from my thing that sends email.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSS366AAoJED/jpRoe7/ujyREIAKb2xTXWR8xLdVpj2K8Dub9W
jSuMtWycMgSW5nkJAOCwA+uJuX47/v7tzejNut1E76oRaAHwEn1fufiWGdT+Dbju
f4BycdI5Pl3NTRuYcFBas32+lbFeyw+gLClczUjfE+fe/pmHiaXAXra6Alai40z8
77B/xGQwrpVyla4S8JHP4CY/p6FHuI5JDs+ghvVESUEK2DHJdNt5R2oLSBy4ZNQw
BTzAf6qvflFUWhpWOkIkzIzo0c5FsJ/nYiVWpWyAjdV1NgufPdZ8ZKIoNx92iJBP
aD1G7h9fQh3E2AU/6VHPvPdekQ5NPzehXtH8ywNFMw16oFbXkZ6/eUYUpJ50YZ8=
=3Yig
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware accelerated crypto

[Joshua Datko]

I was looking into this for the BeagleBone black [1], which has
on-chip accelerators for AES, SHA (1 I think), and md5.  The TI
processor also has a HWRNG.  My belief was that by using the cryptodev
kernel module [2] I could get this working, but I ran in some issues
building the kernel and then I was caught up in other things.

I'm not sure if my approach was flawed or what, but maybe it helps someone here.

Josh

[1] http://datko.net/2013/09/22/quest_bbb_crypto/
[2] http://cryptodev-linux.org/

On Tue, Oct 1, 2013 at 2:35 PM, jason  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I would love to do all this actually but I never managed to get the hw
> accelerated crypto (ssl/tls) bits working to experiment with. I'd be
> up for restarting this if I knew I could consult with one or two
> others who had a genuine interest in this.
> - -Jason
>
> On 10/01/2013 08:26 PM, Jeroen Massar wrote:
>> On 2013-10-01 21:20, Andy Isaacson wrote:
>>> On Tue, Oct 01, 2013 at 06:45:52PM +, jason wrote:
 I'm not sure why I missed this first post but I'm very
 interested in working on this project with whomever is
 interested. I  bought a pogoplug v2 specifically to test it's
 usefulness as a tor exit or relay.
>>>
>>> First step is, run "openssl speed rsa" and post the output to the
>>> list. While you're at it you may as well post the AES and SHA
>>> results as well. Heck, just run the whole "openssl speed" test
>>> (should take less than 20 minutes) and post the whole thing. :)
>>>
>>> Also details on what CPU/RAM it has, and information about the
>>> kernel and OpenSSL package you are testing, would be useful.
>>> "dmesg" output and the contents of /proc/cpuinfo may be helpful.
>>
>> Maybe a good idea to put the output in the wiki somewhere?
>>
>> Greets, Jeroen
>>
>> ___ tor-relays mailing
>> list tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSSzIUAAoJEOXtwcWdKrpuw1oP/RW+ZvMVTDAL0PrKniMB+skZ
> gZf/G2grWaGHzOyo3rC0er8iZdfFY1lN6SB/NWUR7K1xAIvnARRv5Y/N62f9T5O4
> a3bOu61T0XtZ3CeGVtA9Op9QmCOC/UOMebVh4Fa1/Ksb7eEpcne7JcCpW4wnGLHO
> iL+nHDEhyfCjYtBQHa471RaIha+D25yKMIaEhjol9daEbW3PdryzHH7F7mVOYwiT
> W+cCeu5NnHRp9FIwOXTPWwaTLro4XsORLcuJzXjF2Gz6k/HXF1yi1eBv9ljvsa5y
> /ZrpzYqk6gE6zr51GolIypIMm4bLnuzs5ld4XsXT2rdJUSgBKpzydqdn0UZplVKa
> 4Tes7s/8WQCK0CGQvguhQYxUTzF9J/5PtWRBtb9UBM7Zzz1YLFEesQH4kGtevviO
> K8wInsAXcJjAYiPY51eoMXCz38qqHlhy9v/20cg8erJrC7K/r4OlmtDGBegrNI7G
> joHi+HsthFHcGs7AZb2dxSozO9+jt26gtG4u7XDdoEzF5hOJZBopjilERuNRUxSZ
> QHhUdPMh7UFOmYDNkrisF6qPImuuKtQf5NLQ0NaeOrXCwzgJTc4vMk9brAE2kZ0P
> lv389MO7d7AnvtMwr/fIjoZHTCgGuCQU0iA5baeid/FlfWsaHudkAI+7w77qRLCN
> dj7XKgeHH8XghTToTxaB
> =TTnt
> -END PGP SIGNATURE-
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware accelerated crypto

[Jeroen Massar]

On 2013-10-01 21:20, Andy Isaacson wrote:
> On Tue, Oct 01, 2013 at 06:45:52PM +, jason wrote:
>> I'm not sure why I missed this first post but I'm very interested in
>> working on this project with whomever is interested. I  bought a
>> pogoplug v2 specifically to test it's usefulness as a tor exit or relay.
> 
> First step is, run "openssl speed rsa" and post the output to the list.
> While you're at it you may as well post the AES and SHA results as well.
> Heck, just run the whole "openssl speed" test (should take less than 20
> minutes) and post the whole thing. :)
> 
> Also details on what CPU/RAM it has, and information about the kernel
> and OpenSSL package you are testing, would be useful.  "dmesg" output
> and the contents of /proc/cpuinfo may be helpful.

Maybe a good idea to put the output in the wiki somewhere?

Greets,
 Jeroen

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware accelerated crypto

[jason]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I would love to do all this actually but I never managed to get the hw
accelerated crypto (ssl/tls) bits working to experiment with. I'd be
up for restarting this if I knew I could consult with one or two
others who had a genuine interest in this.
- -Jason

On 10/01/2013 08:26 PM, Jeroen Massar wrote:
> On 2013-10-01 21:20, Andy Isaacson wrote:
>> On Tue, Oct 01, 2013 at 06:45:52PM +, jason wrote:
>>> I'm not sure why I missed this first post but I'm very
>>> interested in working on this project with whomever is
>>> interested. I  bought a pogoplug v2 specifically to test it's
>>> usefulness as a tor exit or relay.
>> 
>> First step is, run "openssl speed rsa" and post the output to the
>> list. While you're at it you may as well post the AES and SHA
>> results as well. Heck, just run the whole "openssl speed" test
>> (should take less than 20 minutes) and post the whole thing. :)
>> 
>> Also details on what CPU/RAM it has, and information about the
>> kernel and OpenSSL package you are testing, would be useful.
>> "dmesg" output and the contents of /proc/cpuinfo may be helpful.
> 
> Maybe a good idea to put the output in the wiki somewhere?
> 
> Greets, Jeroen
> 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSSzIUAAoJEOXtwcWdKrpuw1oP/RW+ZvMVTDAL0PrKniMB+skZ
gZf/G2grWaGHzOyo3rC0er8iZdfFY1lN6SB/NWUR7K1xAIvnARRv5Y/N62f9T5O4
a3bOu61T0XtZ3CeGVtA9Op9QmCOC/UOMebVh4Fa1/Ksb7eEpcne7JcCpW4wnGLHO
iL+nHDEhyfCjYtBQHa471RaIha+D25yKMIaEhjol9daEbW3PdryzHH7F7mVOYwiT
W+cCeu5NnHRp9FIwOXTPWwaTLro4XsORLcuJzXjF2Gz6k/HXF1yi1eBv9ljvsa5y
/ZrpzYqk6gE6zr51GolIypIMm4bLnuzs5ld4XsXT2rdJUSgBKpzydqdn0UZplVKa
4Tes7s/8WQCK0CGQvguhQYxUTzF9J/5PtWRBtb9UBM7Zzz1YLFEesQH4kGtevviO
K8wInsAXcJjAYiPY51eoMXCz38qqHlhy9v/20cg8erJrC7K/r4OlmtDGBegrNI7G
joHi+HsthFHcGs7AZb2dxSozO9+jt26gtG4u7XDdoEzF5hOJZBopjilERuNRUxSZ
QHhUdPMh7UFOmYDNkrisF6qPImuuKtQf5NLQ0NaeOrXCwzgJTc4vMk9brAE2kZ0P
lv389MO7d7AnvtMwr/fIjoZHTCgGuCQU0iA5baeid/FlfWsaHudkAI+7w77qRLCN
dj7XKgeHH8XghTToTxaB
=TTnt
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware accelerated crypto

[Andy Isaacson]

On Tue, Oct 01, 2013 at 06:45:52PM +, jason wrote:
> I'm not sure why I missed this first post but I'm very interested in
> working on this project with whomever is interested. I  bought a
> pogoplug v2 specifically to test it's usefulness as a tor exit or relay.

First step is, run "openssl speed rsa" and post the output to the list.
While you're at it you may as well post the AES and SHA results as well.
Heck, just run the whole "openssl speed" test (should take less than 20
minutes) and post the whole thing. :)

Also details on what CPU/RAM it has, and information about the kernel
and OpenSSL package you are testing, would be useful.  "dmesg" output
and the contents of /proc/cpuinfo may be helpful.

-andy
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware accelerated crypto

[jason]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm not sure why I missed this first post but I'm very interested in
working on this project with whomever is interested. I  bought a
pogoplug v2 specifically to test it's usefulness as a tor exit or relay.
- -Jason

On 10/01/2013 06:39 PM, Andy Isaacson wrote:
> On Fri, Sep 13, 2013 at 12:25:47AM +0200, Sarah Vigote wrote:
>> I would like to run a 100Mb/s tor exit node, but I have issues
>> wrt power consumption.
>> 
>> reading 
>> http://ortizaudio.blogspot.fr/2011/10/using-dreamplugs-crypto-chip.html
>>
>> 
it seems dreamplugs has *fast* aes-128-ecb.
>> 
>> Does anyone have any experience running a node based on cheap
>> crypto chip (dreamplug, marvell 88F6282, sheeva-core, padlock,
>> ...) ? What performance can I expect out of these ?
> 
> Unfortunately AES is not the primary CPU consumer on Tor nodes
> right now; we spend a lot more time doing bignum computation for
> TAP circuits.  Crypto accelerators don't work very well for
> bignums.
> 
> It's not a perfect equivalence, but "openssl speed rsa" should give
> a reasonable estimate of how well your chip will do for TAP
> circuit creation.  Here's a dual-core Westmere at 2.1 GHz (should
> be fairly close to a modern Xeon core):
> 
> signverifysign/s verify/s rsa  512 bits 0.000105s 0.07s
> 9548.7 137778.7 rsa 1024 bits 0.000340s 0.21s   2941.1
> 48539.0 rsa 2048 bits 0.002205s 0.70s453.4  14362.8 rsa
> 4096 bits 0.016398s 0.000260s 61.0   3840.3
> 
> A single Xeon core can currently handle most of a 100 Mbps exit
> node's traffic, so you should look for a dual-core chip that
> delivers at least 1500 sign/s on rsa-1024.  Unfortunately I doubt
> there are any ARM chips that can compete.
> 
> -andy ___ tor-relays
> mailing list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSSxhfAAoJEOXtwcWdKrpuG4cP/04KspbxenNkcLXvXWPdiUTi
UJlg2EOphyHlMp8lUPQPcHprYAWEQUjTpUevxZXNhjhr6oGrw/OVem1Ht74DpjA/
9rg+0z4m/YiRCUCSLtl5aLqE65z8bN9NM00qyppDLCEsu/ogR3qXDibUNjIAjmfg
8qRcoA28xJ3hn0eo21AB1aZ/clkUF5REAPoLeG2K7Nmz1sBznky0NxtdgHx+bPP/
utQg5n797pIUx3PjWsV/PnebeJ2VPFCkM6ZI06jINcYHXVLGn1B/2NklGSUrwNLf
4W7vIWptENHjcsM4XBLcnPt8DzrtNEPKOemKLRledWFOE2Kha/nBqMRoExXjEgbA
1VNE1gbwNIsUEbr1uEuAu2cbfvHXw1wPMWvn9dV+4Kh4srhARiq+4xZ7qRAGxrbr
uf2klMY+brrwf6nLJsbPxAdKWZCLNCe1CIrpb9mX/SJVCb8qWGMXSxnDbpqfZsYU
CxJy2JQ9VeVaPCNypjm2PQprBz2vt/QGlaXELiL446QVveSZIv6e4QCGSSmHPvww
TeqCRkvgGj5tE43On2cj0YBmuLjJXnsA2K3+KrZtshVp1qBQIf3FevhHCzKljdW4
QYn7v/kBWRlko/79iJMp9FP7jL6gsfiHj9NkEjAer04Esnyych5aXpNEv2GXDKyr
8omA70GBANyUybmIk7aW
=hL5v
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware accelerated crypto

[Andy Isaacson]

On Fri, Sep 13, 2013 at 12:25:47AM +0200, Sarah Vigote wrote:
> I would like to run a 100Mb/s tor exit node, but I have issues wrt
> power consumption.
> 
> reading
> http://ortizaudio.blogspot.fr/2011/10/using-dreamplugs-crypto-chip.html
> it seems dreamplugs has *fast* aes-128-ecb.
> 
> Does anyone have any experience running a node based on cheap crypto
> chip (dreamplug, marvell 88F6282, sheeva-core, padlock, ...) ? What
> performance can I expect out of these ?

Unfortunately AES is not the primary CPU consumer on Tor nodes right
now; we spend a lot more time doing bignum computation for TAP
circuits.  Crypto accelerators don't work very well for bignums.

It's not a perfect equivalence, but "openssl speed rsa" should give a
reasonable estimate of how well your chip will do for TAP circuit
creation.  Here's a dual-core Westmere at 2.1 GHz (should be fairly
close to a modern Xeon core):

  signverifysign/s verify/s
rsa  512 bits 0.000105s 0.07s   9548.7 137778.7
rsa 1024 bits 0.000340s 0.21s   2941.1  48539.0
rsa 2048 bits 0.002205s 0.70s453.4  14362.8
rsa 4096 bits 0.016398s 0.000260s 61.0   3840.3

A single Xeon core can currently handle most of a 100 Mbps exit node's
traffic, so you should look for a dual-core chip that delivers at least
1500 sign/s on rsa-1024.  Unfortunately I doubt there are any ARM chips
that can compete.

-andy
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware accelerated crypto

[blob]

Am Fri, 13 Sep 2013 00:25:47 +0200
schrieb Sarah Vigote :

I once meassured the performance of the padlock crypto chip
on a VIA Esther C7 1500 MHz processor. Result:
AES-128 cbc with padlock is about 14 times faster compared to the C7
with padlock disabled.


regards,
Fabian
> hi,
> 
> I would like to run a 100Mb/s tor exit node, but I have issues wrt
> power consumption.
> 
> reading
> http://ortizaudio.blogspot.fr/2011/10/using-dreamplugs-crypto-chip.html
> it seems dreamplugs has *fast* aes-128-ecb.
> 
> Does anyone have any experience running a node based on cheap crypto
> chip (dreamplug, marvell 88F6282, sheeva-core, padlock, ...) ? What
> performance can I expect out of these ?
> 
> regards,
> sv
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] hardware accelerated crypto

[Sarah Vigote]

hi,

I would like to run a 100Mb/s tor exit node, but I have issues wrt
power consumption.

reading
http://ortizaudio.blogspot.fr/2011/10/using-dreamplugs-crypto-chip.html
it seems dreamplugs has *fast* aes-128-ecb.

Does anyone have any experience running a node based on cheap crypto
chip (dreamplug, marvell 88F6282, sheeva-core, padlock, ...) ? What
performance can I expect out of these ?

regards,
sv
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware

[grarpamp]

>> A10-6800K (4 x 4.1GHz) would be decent.
>
> It doesn't seem to support ECC

It doesn't. And for those that recognize its importance, that's
been an kind of weakness of AMD for some time. Actually
for both AMD and Intel, it's treated as a price premium
instead of just 8+n extra gates and logic.

> It's very silly to not specify ECC RAM for a server.

It should be in all systems IMO too, even with crypto over
circuits and ZFS on disk. But I not sure the CPU registers,
or the rest of the gates on the die, have any such hardware
protection beyond the lid on top and the fiberglass on the
bottom... haven't looked into it. Or that the makeup of the
Internet/services as a whole use ECC. Tor seems more
weighted to pushing reproducible bits, than to first production
and storage of your own valuable work product.

> like serial console BIOS support and

It's nice if your model involves needing to go to BIOS, such
as being tied to hardware raid there.

> 1U form factor

The port stacks can be cut down / removed if need be.
Another problem is finding low profile ram to go in non-angled
slots. The 'enthusiast' influx to the ram market is annoying yet
the unneeded 'heatsinks' (aka bling) can also be removed.

> the r8139 (iirc)
> chip/driver lacking interrupt coalescing features. Upgrading to an
> Intel e1000e fixed the problem.

Yes, Intel has always had very good nics and supplies docs/code.
I think a85x boards commonly have rt8111.

> The kind of ISPs that offer competitive pricing on bandwidth tend to
> prefer commercially integrated servers, preferably sourced from vendors
> they're familiar with.

That means Intel, Dell, HP and the like.
I'd hesitate to tie bandwidth price to what some techs want.
It's more about how much the ISP buys, if you're small retail remote
hands using or a large self-serve cage, and if it's in a neutral DC.

> That way when your server crashes and needs a
> reboot at 2AM, the tech in the data center doesn't

This is a bit crossed. A true server board should have a
hw watchdog that will autoreboot the OS. Similarly,
with a good server, pulling the plug should be all a
tech needs to do to clear all stuck cases short of
hardware failure. You need a good OS/FS for that.

>> Be careful, Intel likes to promote HT instead of full cores.
>
> That's a really funny claim

Some of their retail marketing I've seen is not so clear, as
in 'Here are 8 virtual things, footnote asterisk fine print - really
backed by 4 real things'. Their server side online is better.

> a single thread can use nearly all of
> the resources on a core. HT is useful

Sure, if your workload is not weighted to single threads/processes
that you can itemize/count as being under the number of real cores.

> AMD Bulldozer, OTOH, claims to have [unit pairing/starvation]

I do often forget that overall when considering some loads :(

> actual work done per watt on CPU intensive workloads.

Intel often beats AMD on power, even if only due to die
process size. Datacenters tend not to line item 1RU's
for actual power used unless you're at 1/4 rack or more
and they have metered managed outlets, the costs of
which are passed on to you as well. As is wasted power.
In the end, for small customers, the DC averages a single
price to you into which you fit whatever box you want. A
home or corporate DC is different because you can mind
your power there to direct/immediate savings.

> AMD unfortunately doesn't seem to have a competitive
> server CPU these days.  It's possible that Piledriver improves the
> situation, but the analysis I saw did not make me optimistic that it
> would be competitive with Ivy Bridge.

I didn't mean to imply that such a system was true
physical server class, but that it could serve the logical
function of a decent server/host for the Tor application.
Particularly considering the cost per node per megabit as
opposed to maximum yield regardless of cost. Real server
hardware tends to start well above $1kUSD. Factoring in the
performance differences and passing on some features,
distributing a lower cost box may be a win there. As a counter
to that idea, It might also be useful to consider initial cost vs.
megabits delivered over time... if you do not expect to be kicked
from DC to DC thus eating multiple shipping costs as add-on
capital.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware

[Moritz Bartl]

On 12.07.2013 08:02, Mike Perry wrote:
> This sounds right (~100Mbit per CPU core without AES-NI), but it would
> be good to hear Moritz weigh in here with some additional datapoints for
> AES-NI. Last I heard, AES-NI gets you ~300Mbit per core, but I have no
> direct experience myself.

Yes, 300Mbit/s is my estimate as well. We publish some amount of
statistics at https://torservers.net/munin/ (axigy1, axigy2 and
voxility1 are on Gbit).

> You probably also shouldn't run too many of these sized relays by
> yourself, either. It is generally considered poor form to run too much
> of the Tor network by yourself until other people can catch up and
> balance your efforts. I would look for ways to decentralize/delegate
> once you got beyond a couple gbits or so for this reason. Please feel
> free to ask the list for suggestions on legal and admin structure for
> accomplishing this.

Happy to help! If you have any questions you can also reach me via
Jabber (same address as this email address).

-- 
Moritz Bartl
https://www.torservers.net/
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware

[Andy Isaacson]

On Fri, Jul 12, 2013 at 06:45:58PM -0400, grarpamp wrote:
> > AMD doesn't seem to make any server CPUs that are useful for this
> > application, unfortunately.
> 
> Really, how so? Many AMD CPU's have AES-NI. Even the
> A10-6800K (4 x 4.1GHz) would be decent.

That's not a server CPU.  It doesn't seem to support ECC, and it doesn't
go in boards that are well designed for server applications (with things
like serial console BIOS support and 1U form factor).

> That plus an a85x mainboard (1Gbit)

That cheap desktop board has a Realtek NIC.  Realtek NICs are
spectacularly bad for server use cases.  We were not able to push 400
Mbps of Tor traffic on a Realtek, possibly due to the r8139 (iirc)
chip/driver lacking interrupt coalescing features.  Upgrading to an
Intel e1000e fixed the problem.  Broadcom tg3 also works fine.  The
newer Broadcom (nx or something?) chips should also be fine.

> and 8GB ddr3-2133 is $300.

It's very silly to not specify ECC RAM for a server.

> Add some case+ps.

The kind of ISPs that offer competitive pricing on bandwidth tend to
prefer commercially integrated servers, preferably sourced from vendors
they're familiar with.  That way when your server crashes and needs a
reboot at 2AM, the tech in the data center doesn't have to puzzle out
the buttons and connectors on some utterly random box that you found on
a street corner.

> Be careful, Intel likes to promote HT instead of full cores.

That's a really funny claim, since exactly the opposite seems true from
my point of view.  Intel clearly specifies how many cores and how many
HTs are provided on each CPU, and a single thread can use nearly all of
the resources on a core.  HT is useful, on Sandy Bridge, for providing fine
grained parallelism to let the CPU get useful work done during cache
miss stalls and similar, but HT is not necessary to get full ALU
utilization for in-cache codes.  AMD Bulldozer, OTOH, claims to have 8
cores, but they come in "bundles" of 2, and the "8 core" Bulldozer has
approximately the same number of ALUs and other CPU resources as the 4
core Intel chips.  As a result, each individual Bulldozer "core" (really
more like a HT on Sandy Bridge) is fairly slow in terms of
operations/clock, and AMD's resource scheduler doesn't seem to be very
good at dynamic resource allocation.

The end result of this threading nonsense is, on an Intel CPU you can
get 90% of the CPU throughput doing useful work with 4 threads, while on
a Bulldozer you need 8 threads to get 90% throughput.  For Tor that
means 8 daemons rather than 4, a significantly higher annoyance.

Making matters worse, Bulldozer has at least a 20% if not more like 30%
power penalty versus Sandy Bridge, measuring actual work done per watt
on CPU intensive workloads.

That's why I said AMD unfortunately doesn't seem to have a competitive
server CPU these days.  It's possible that Piledriver improves the
situation, but the analysis I saw did not make me optimistic that it
would be competitive with Ivy Bridge.

-andy
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware

[grarpamp]

> AMD doesn't seem to make any server CPUs that are useful for this
> application, unfortunately.

Really, how so? Many AMD CPU's have AES-NI. Even the
A10-6800K (4 x 4.1GHz) would be decent. That plus an a85x
mainboard (1Gbit) and 8GB ddr3-2133 is $300. Add some
case+ps.

https://en.wikipedia.org/wiki/List_of_AMD_Accelerated_Processing_Unit_microprocessors#.22Richland.22_.282013.2C_32_nm.29
https://en.wikipedia.org/wiki/List_of_AMD_FX_microprocessors#.22Vishera.22_.2832_nm_SOI.29
https://en.wikipedia.org/wiki/List_of_AMD_Opteron_microprocessors#Piledriver_based_Opterons

Be careful, Intel likes to promote HT instead of full cores.
There's likely some reviews of HT vs. OS schedulers out there.
Intel/Opteron get pricy very quick, check price vs. performance
vs. the price delta to get a second AMD node up at 2 x nMbps.
A lot of the price may be in die/power and cache, which
may not be of concern.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware

[Mike Perry]

Andy Isaacson:
> On Thu, Jul 11, 2013 at 08:46:20PM +0200, Andreas Fink wrote:
> > can someone give me hints on what hardware would be best suited to run
> > big fat tor exit nodes connected with multiple 1gbps or 10gps links?
> > We are considering putting some fat boxes near major internet
> > exchanges of the world.
> 
> Modern Xeon, AES-NI is helpful, HT is not very helpful (but not hurtful
> either), higher clock rate is more helpful than more cores.  4GB of RAM
> per core, you can probably get away with 2GB/core but why skimp.
> Noisetor uses most of a 4-core X3350 2.6 GHz to push ~500 Mbps
> symmetric.  That's without AES-NI, so I'd expect a quadcore 2.5 GHz
> AES-NI to be able to fill a 1Gbps pipe.

This sounds right (~100Mbit per CPU core without AES-NI), but it would
be good to hear Moritz weigh in here with some additional datapoints for
AES-NI. Last I heard, AES-NI gets you ~300Mbit per core, but I have no
direct experience myself.

The key thing to know is that Tor is still not great at multithreading.
In fact, the torrc option 'NumCPUs' is mostly useless for relays at
this scale.

For this reason, you want to run one tor daemon per CPU core, with a max
of two per IP, and something like 2-4GB of RAM per daemon like Andy
said. That's why we have noiseexit01a-d, Amunet1-8, manning1-2, etc. 

You probably also shouldn't run too many of these sized relays by
yourself, either. It is generally considered poor form to run too much
of the Tor network by yourself until other people can catch up and
balance your efforts. I would look for ways to decentralize/delegate
once you got beyond a couple gbits or so for this reason. Please feel
free to ask the list for suggestions on legal and admin structure for
accomplishing this.


-- 
Mike Perry


signature.asc
Description: Digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware

[Andy Isaacson]

On Thu, Jul 11, 2013 at 08:46:20PM +0200, Andreas Fink wrote:
> can someone give me hints on what hardware would be best suited to run
> big fat tor exit nodes connected with multiple 1gbps or 10gps links?
> We are considering putting some fat boxes near major internet
> exchanges of the world.

Modern Xeon, AES-NI is helpful, HT is not very helpful (but not hurtful
either), higher clock rate is more helpful than more cores.  4GB of RAM
per core, you can probably get away with 2GB/core but why skimp.
Noisetor uses most of a 4-core X3350 2.6 GHz to push ~500 Mbps
symmetric.  That's without AES-NI, so I'd expect a quadcore 2.5 GHz
AES-NI to be able to fill a 1Gbps pipe.

AMD doesn't seem to make any server CPUs that are useful for this
application, unfortunately.

-andy
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] hardware

[Andreas Fink]

can someone give me hints on what hardware would be best suited to run big fat 
tor exit nodes connected with multiple 1gbps or 10gps links? We are considering 
putting some fat boxes near major internet exchanges of the world.



sent from iPhone
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware accel option in tor alpha

[Sebastian Hahn]

On Apr 1, 2012, at 2:22 PM, Sebastian Urbach wrote:
> Hi Sebastian,

oh hai.

> Do you know if this
> applies to the released 0.3.13-alpha version from the 26th of March ?

It does not, that's why I said it isn't in any released version of tor.
The next one should contain it, until then you're forced to build from
source.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware accel option in tor alpha

[Sebastian Urbach]

Am Sat, 31 Mar 2012 21:52:16 +0200
schrieb Sebastian Hahn :

Hi Sebastian,

And no, im not talking with myself ;-)

> the situation is indeed a bit confusing with openssl 1.0.1. Aesni
> isn't a module anymore, so the hardware accel options no longer
> apply. Tor master (not yet in any released version) automatically
> makes use of aesni as supported by openssl 1.0.1, so either upgrade
> to recent git or wait for the next release.
> 
> You'll then gain support automatically.

Thank you very much for this short info indeed. Do you know if this
applies to the released 0.3.13-alpha version from the 26th of March ? I
did not find any clues in the changelog so im assuming this feature
will be part of the next release ?

Thanks for your help.


-- 
Mit freundlichen Grüßen / Yours sincerely

Sebastian Urbach


Religion is something left over from the infancy of
our intelligence, it will fade away as we adopt
reason and science as our guidelines.


Bertrand Arthur William Russell (1872-1970),
British philosopher, logician, mathematician,
historian, and social critic.


signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware accel option in tor alpha

[Sebastian Hahn]

On Mar 31, 2012, at 9:32 PM, Sebastian Urbach wrote:

> Hi,
> 
> I want to use the "hardware accel" feature with the actual tor alpha
> version 0.2.3.12-alpha1. My CPUs support the Intel AES NI function
> and the kernel module is enabled and running well.
> 
> Im running OpenSSL 1.0.1, the debian dev told me that there is
> no dynamic loadable aes ni shipped though its supporting th function.
> Im pretty confused about the options int the torrc right now.
> 
> I have enabled "hardware accel" but did not define any dynamic
> loadable engine anymore because there is no one according to the
> debian dev and also the output from "openssl engine". The debug log
> does not show any enabled aes / evp functions what so ever.
> 
> Im stuck right now, does anybody have some advice, woudl be
> awesome ;-) ?
> 
> Thanks

the situation is indeed a bit confusing with openssl 1.0.1. Aesni
isn't a module anymore, so the hardware accel options no longer
apply. Tor master (not yet in any released version) automatically
makes use of aesni as supported by openssl 1.0.1, so either upgrade
to recent git or wait for the next release.

You'll then gain support automatically.

CC'ing Nick here to sanity-check my understanding, I haven't been
following development too much in the past few days :/
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] hardware accel option in tor alpha

[Sebastian Urbach]

Hi,

I want to use the "hardware accel" feature with the actual tor alpha
version 0.2.3.12-alpha1. My CPUs support the Intel AES NI function
and the kernel module is enabled and running well.

Im running OpenSSL 1.0.1, the debian dev told me that there is
no dynamic loadable aes ni shipped though its supporting th function.
Im pretty confused about the options int the torrc right now.

I have enabled "hardware accel" but did not define any dynamic
loadable engine anymore because there is no one according to the
debian dev and also the output from "openssl engine". The debug log
does not show any enabled aes / evp functions what so ever.

Im stuck right now, does anybody have some advice, woudl be
awesome ;-) ?

Thanks



-- 
Mit freundlichen Grüßen / Yours sincerely

Sebastian Urbach


Religion is something left over from the infancy of
our intelligence, it will fade away as we adopt
reason and science as our guidelines.


Bertrand Arthur William Russell (1872-1970),
British philosopher, logician, mathematician,
historian, and social critic.


signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays