Hi to all - I have a question: In case there is a strong relay ie 1Gbit/s, enough cores and RAM so the HW is not limiting. Let's further assume only one IP. Could a single Tor daemon on Debian be a bottle neck? If yes, could be more performance to start two (or more) daemons and bind the first OR Port to :443 and the second to :8080. Both at the same 'eth' interface? Both OR Ports are based on the same IP so they would be the same family member. Thanks for your answer. My response might have some delay. Sorry for that. Regards, Felix ==========---------- - - - - - - - - - - ----------========== -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (MingW32) mQENBFL/5VoBCAC8l2gGmuy2hZf866dDkwzOvMkyJlfnFZU6T5LWe4uPIx0a8R1U cmj/Vut2yUCaJgvFpdOVA3mmXC58zoDeiW7Um6q6otD6BR2hXdgyBTAgqkQ0BsYx epb4UXBz/u3TJmv655fBnXeDgCB8L5BIkcsmX6EoBNUs6a3TPMhX3UXOtEKLXJeZ 2QtoDxwXqHNSmW7jLq+qkpriVDqxDTFv+muZRE+Zn/6PZpEASvpSdVdT/1giEMUL QQFIP6cBPY2GYIaNCO1dYRj9ebM7ewWjCiOiOw6/eylxan8vfFntgaPU3J7W2wJp RiRtUIjT+TDycVyNk7gy4wV2Rj8+58+Krk1tABEBAAG0IEZlbGl4IDx6d2llYmVs QHF1YW50ZW50dW5uZWwuZGU+iQE5BBMBAgAjBQJS/+VaAhsPBwsJCAcDAgEGFQgC CQoLBBYCAwECHgECF4AACgkQC2jb92rYqyMGxQf/d9oJf0qpgXZaUmcqujQ3DVsc uvYOnK2MJCpDIvvZYdQTcnG2jz8/na1ZyfAGeKhYZ18ypONwSQYthC17L5GHQ2H3 Pg/H0GARtx4aJR5TtIKnhPR8yYdlikCuTBb5QSFJUUtEz91SqDW7EXNbMC4RRSEd BWWirADCJWitoR3JCC13r+CF6TCFDluClAht/t56f7prBzARVYWmlbgYD2yx4Uzs FOl0vvhW2o9dpVaLZ6mSHAyNzefCFcNumRUxqa+V6nY94dd8BV8xH0lOd1xaMtZW HuxIU9Sbh13OlJyBAvVffVBL+4sEOpc8XB6Yl/pmyjEjUSvC7lP3T+Ix9Mnk/A== =kfXw -----END PGP PUBLIC KEY BLOCK-----
On 03/03/2014 11:53 PM, Felix wrote:
In case there is a strong relay ie 1Gbit/s, enough cores and RAM so the HW is not limiting. Let's further assume only one IP.
Could a single Tor daemon on Debian be a bottle neck? If yes, could be more performance to start two (or more) daemons and bind the first OR Port to :443 and the second to :8080. Both at the same 'eth' interface? Both OR Ports are based on the same IP so they would be the same family member.
Yes, you do want to run multiple Tor processes on a high bandwidth machine as Tor currently does not scale well across multiple CPU cores. You will notice that you will hit a CPU limit at ~100 Mbps (or ~300-400 Mbps with a CPU that supports AES-NI crypto acceleration). But, currently, you can only run two Tor process per IP address. Relays in the same /16 IPv4 subnets are considered part of one family automatically. -- Moritz Bartl https://www.torservers.net/
Hi Moritz, im running a few high bandwidth relays, and i'm also interested in tuning the performance - at the moment i have experienced following things regarding AES-NI acceleration: With an upgrade to ubuntu 13.10 x64 there seem to be no more support for aesni module - so it doesnt seem to be usable any more. With older ubuntu releases it works. I've recognized that some configurations are running easily with an higher throughput - but could not figure out whats the reason for it. My VPS'es are almost running in an KVM environment - but the 2 fastest ones running on OpenVZ hypervisor. Processor and Hardware underlying are not identical (corei7 or Xeon E3 in this case) so this doesnt seem to be a reason though for the different speed. But anyway im interested on reactivating that function as it seems to really speedup relay's speed. Thanks, Geri 2014-03-04 0:40 GMT+01:00 Moritz Bartl <moritz@torservers.net>:
On 03/03/2014 11:53 PM, Felix wrote:
In case there is a strong relay ie 1Gbit/s, enough cores and RAM so the HW is not limiting. Let's further assume only one IP.
Could a single Tor daemon on Debian be a bottle neck? If yes, could be more performance to start two (or more) daemons and bind the first OR Port to :443 and the second to :8080. Both at the same 'eth' interface? Both OR Ports are based on the same IP so they would be the same family member.
Yes, you do want to run multiple Tor processes on a high bandwidth machine as Tor currently does not scale well across multiple CPU cores. You will notice that you will hit a CPU limit at ~100 Mbps (or ~300-400 Mbps with a CPU that supports AES-NI crypto acceleration).
But, currently, you can only run two Tor process per IP address.
Relays in the same /16 IPv4 subnets are considered part of one family automatically.
-- 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
Hi, On 03/04/2014 08:19 AM, toxi roxi wrote:
With an upgrade to ubuntu 13.10 x64 there seem to be no more support for aesni module - so it doesnt seem to be usable any more. With older ubuntu releases it works.
https://www.torservers.net/wiki/setup/server#aes-ni_crypto_acceleration Does this help already?
I've recognized that some configurations are running easily with an higher throughput - but could not figure out whats the reason for it. My VPS'es are almost running in an KVM environment - but the 2 fastest ones running on OpenVZ hypervisor.
I tried KVM and OpenVZ some years ago for high bandwidth relays, and couldn't get it to make decent throughput at all. I now run all our fast relays "on bare metal".
But anyway im interested on reactivating that function as it seems to really speedup relay's speed.
Unless you max out /all/ your CPU cores, you can and should simply spin up more Tor processes in parallel, one per CPU core, and limit their bandwidth so they never hit 100% CPU usage. -- Moritz Bartl https://www.torservers.net/
Hi Moritz, i know that link and thats what i have done to setup intel aesni acceleration - but it seems that this tweak is not available anymore on ubuntu 13.10 thats what i've meant. i found also some hints in google that this is no longer working now. this is in my startup log: Mar 04 11:54:24.000 [warn] Unable to load dynamic OpenSSL engine "aesni". Mar 04 11:54:24.000 [notice] Default OpenSSL engine for RSA is RSAX engine support [rsax] Mar 04 11:54:24.000 [warn] TLS error while generating certificate: could not load the shared library (in DSO support routines:DLFCN_LOAD:---) Mar 04 11:54:24.000 [warn] TLS error while generating certificate: could not load the shared library (in DSO support routines:DSO_load:---) Mar 04 11:54:24.000 [warn] TLS error while generating certificate: dso not found (in engine routines:DYNAMIC_LOAD:---) Mar 04 11:54:24.000 [warn] TLS error while generating certificate: no such engine (in engine routines:ENGINE_by_id:---) but as you can see aesni_intel is activated: lsmod | grep aes aesni_intel 55624 0 aes_x86_64 17131 1 aesni_intel lrw 13286 1 aesni_intel glue_helper 13990 1 aesni_intel ablk_helper 13597 1 aesni_intel cryptd 20359 3 ghash_clmulni_intel,aesni_intel,ablk_helper i found some information on 2 pages that aesni_intel is no longer available to openssl 1.0.1 so this accelleration is not usable anymore - as ubuntu 13.10 is delivered with that openssl version im also affected of that change. i found some informations here: https://trac.torproject.org/projects/tor/ticket/6158 with a hint for reading here https://lists.torproject.org/pipermail/tor-relays/2012-March/001260.html is there any other way to get this acceleration working? thanks for your support! 2014-03-04 9:10 GMT+01:00 Moritz Bartl <moritz@torservers.net>:
Hi,
On 03/04/2014 08:19 AM, toxi roxi wrote:
With an upgrade to ubuntu 13.10 x64 there seem to be no more support for aesni module - so it doesnt seem to be usable any more. With older ubuntu releases it works.
https://www.torservers.net/wiki/setup/server#aes-ni_crypto_acceleration
Does this help already?
I've recognized that some configurations are running easily with an higher throughput - but could not figure out whats the reason for it. My VPS'es are almost running in an KVM environment - but the 2 fastest ones running on OpenVZ hypervisor.
I tried KVM and OpenVZ some years ago for high bandwidth relays, and couldn't get it to make decent throughput at all. I now run all our fast relays "on bare metal".
But anyway im interested on reactivating that function as it seems to really speedup relay's speed.
Unless you max out /all/ your CPU cores, you can and should simply spin up more Tor processes in parallel, one per CPU core, and limit their bandwidth so they never hit 100% CPU usage.
-- 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
On 03/04/2014 01:00 PM, toxi roxi wrote:
i found some information on 2 pages that aesni_intel is no longer available to openssl 1.0.1
Wrong. It is no longer a _separate module_ and will be used automatically without any further configuration in torrc. This is also mentioned in our setup instructions. -- Moritz Bartl https://www.torservers.net/
On Tue, Mar 04, 2014 at 01:00:15PM +0100, toxi roxi wrote:
i know that link and thats what i have done to setup intel aesni acceleration - but it seems that this tweak is not available anymore on ubuntu 13.10 thats what i've meant.
As Moritz says, the *config* is removed, because aes-ni is no longer a *separate* module, it's built in to core openssl.
i found also some hints in google that this is no longer working now.
this is in my startup log: Mar 04 11:54:24.000 [warn] Unable to load dynamic OpenSSL engine "aesni". Mar 04 11:54:24.000 [notice] Default OpenSSL engine for RSA is RSAX engine support [rsax] Mar 04 11:54:24.000 [warn] TLS error while generating certificate: could not load the shared library (in DSO support routines:DLFCN_LOAD:---) Mar 04 11:54:24.000 [warn] TLS error while generating certificate: could not load the shared library (in DSO support routines:DSO_load:---) Mar 04 11:54:24.000 [warn] TLS error while generating certificate: dso not found (in engine routines:DYNAMIC_LOAD:---) Mar 04 11:54:24.000 [warn] TLS error while generating certificate: no such engine (in engine routines:ENGINE_by_id:---)
but as you can see aesni_intel is activated: lsmod | grep aes aesni_intel 55624 0
Note that the kernel module is not required for openssl, instead you just need to verify that aes is in /proc/cpuinfo: grep --color aes /proc/cpuinfo (The aesni_intel kernel module gives you faster encrypted disks and similar in-kernel cryptography systems. The "aes cpuflag" ensures that the AES-NI instructions are available to applications.) -andy
participants (4)
-
Andy Isaacson -
Felix -
Moritz Bartl -
toxi roxi