-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, A Tor relay currently going 33MB/s could go a lot faster but CPU is at 93% usage - this is the bottleneck. Here is the output of /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz stepping : 5 microcode : 0x11 cpu MHz : 3068.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 6132.24 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: it also goes down to processor 1 - processor 7 Any ideas how this could be boosted? OS is Debian wheezy. No aes-ni hardware acceleration, no openssl benchmarking or customization currently. advices? Thank you. - -- s7r PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUDuRTAAoJEIN/pSyBJlsRLqYH/iSCtC9r/7/DBCG2qqUGPEgY TELvt+UMGyMP6ncNJH+vDEdHO4BBlSMzFQdj2sKyO3hOT5492cIOaT3gGokaDApL W913yqUkIfiUT6FUWJ6g4/LUt25pMG25Ednr/ZJJXR/pR+Ym3T3ytg+MSwRBmpEe +h26Q7qvd/p4f6VhTR0sEsxQfDLVXrEsj3kn0BL0rLklN5zH/bqmIsK2hio5Nl3H KBvbvyt+JbLhA/4+jygT6AygHDH9arpXWEh3ZcJVn7mE0OmPAvukdlLUj70K5F7r cCeMakcGBbSzit5tY7jUmSvkUewVBhAxAZmv1hgNnuCoSrGPtQZseCbM06cry+k= =TyKF -----END PGP SIGNATURE-----
On 09/09/2014 01:28 PM, s7r wrote:
A Tor relay currently going 33MB/s could go a lot faster but CPU is at 93% usage - this is the bottleneck. Here is the output of /proc/cpuinfo
93% CPU across _all_ cores for 33MB/s sounds a bit too heavy. Are you maybe only running one instance of Tor and it maxes out one core? Spread the load to more cores then, and limit each of the relay processes so it stays well below 90%. https://www.torservers.net/wiki/setup/server#multiple_tor_processes -- Moritz Bartl https://www.torservers.net/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/9/2014 2:43 PM, Moritz Bartl wrote:
On 09/09/2014 01:28 PM, s7r wrote:
A Tor relay currently going 33MB/s could go a lot faster but CPU is at 93% usage - this is the bottleneck. Here is the output of /proc/cpuinfo
93% CPU across _all_ cores for 33MB/s sounds a bit too heavy. Are you maybe only running one instance of Tor and it maxes out one core? Spread the load to more cores then, and limit each of the relay processes so it stays well below 90%.
https://www.torservers.net/wiki/setup/server#multiple_tor_processes
Yes, it's one Tor instance - I thought it will use the network better this way. How many Tor instances should be there 4 or 8? - -- s7r PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUDuf5AAoJEIN/pSyBJlsRz44H/3ayBCp1LaXQb2FxTau1ME/m W2Dft0vHQVzSR3cmx1mER/qD5ltVDsq0i4FgnoHhOA6quKlRyQYKtBkCZ3AQK1Sh VGio0NRBEry+TpqJoD9xnkcE9ubUrRvNf3MnLYG14ooNoo65fpME/ie3xuVNfPp/ aaWoZVh1sICy+xsc9dT6HkeSDAaT/QCjLXZZ4HtYfk2UcQD63sCEukXrq/IRgR+E ylhvDacgFREQoH+M+58xLmCmZcngYwurDmGbjYaVOiRvp0udpGvhqGdAn/IPrpHi EB4MC/C2DVIL27B0uXebMuYdJ2wGJ+RiZ6zS0519cb/soCmnM1DUNalBSel0lVM= =6XFi -----END PGP SIGNATURE-----
On 09/09/2014 01:43 PM, s7r wrote:
93% CPU across _all_ cores for 33MB/s sounds a bit too heavy. Are you maybe only running one instance of Tor and it maxes out one core? Spread the load to more cores then, and limit each of the relay processes so it stays well below 90%. Yes, it's one Tor instance - I thought it will use the network better this way. How many Tor instances should be there 4 or 8?
You can run as many instances as you like, but a maximum of 2 per IP. -- Moritz Bartl https://www.torservers.net/
Hi, AES-NI is by far the most powerful feature from your list. From my point of view absolutely necessary. If theres no CPU Upgrade reachable for you i suppose you can wait for the tor alpha version to become fully multithread capable. This should be reality in the near future. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, A Tor relay currently going 33MB/s could go a lot faster but CPU is at 93% usage - this is the bottleneck. Here is the output of /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz stepping : 5 microcode : 0x11 cpu MHz : 3068.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 6132.24 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: it also goes down to processor 1 - processor 7 Any ideas how this could be boosted? OS is Debian wheezy. No aes-ni hardware acceleration, no openssl benchmarking or customization currently. advices? Thank you. - -- s7r PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUDuRTAAoJEIN/pSyBJlsRLqYH/iSCtC9r/7/DBCG2qqUGPEgY TELvt+UMGyMP6ncNJH+vDEdHO4BBlSMzFQdj2sKyO3hOT5492cIOaT3gGokaDApL W913yqUkIfiUT6FUWJ6g4/LUt25pMG25Ednr/ZJJXR/pR+Ym3T3ytg+MSwRBmpEe +h26Q7qvd/p4f6VhTR0sEsxQfDLVXrEsj3kn0BL0rLklN5zH/bqmIsK2hio5Nl3H KBvbvyt+JbLhA/4+jygT6AygHDH9arpXWEh3ZcJVn7mE0OmPAvukdlLUj70K5F7r cCeMakcGBbSzit5tY7jUmSvkUewVBhAxAZmv1hgNnuCoSrGPtQZseCbM06cry+k= =TyKF -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Can a bridge carry client traffic even though the bridge hasn't been assigned to a pool? This is evidently the case for my bridge. It's been running for quite a while and registering respectable bandwidth and client use. Uptime has been near 100%. The only downtimes have been to install OS (win7) updates and other housekeeping. I usually do this housekeeping monthly rather than weekly. As I recall, for previous restarts I've seen pool assignments within a few hours. They've sometimes been https, sometimes email. But this last restart has been running two weeks and the bridge DB shows no pool assignment. Has anyone else experienced this? What's the remedy? If it would help anyone figure this out I can post details, graphs, etc. along as they don't compromise the bridge. - eliaz
eliaz transcribed 0.9K bytes:
Can a bridge carry client traffic even though the bridge hasn't been assigned to a pool?
This is evidently the case for my bridge. It's been running for quite a while and registering respectable bandwidth and client use. Uptime has been near 100%. The only downtimes have been to install OS (win7) updates and other housekeeping. I usually do this housekeeping monthly rather than weekly.
As I recall, for previous restarts I've seen pool assignments within a few hours. They've sometimes been https, sometimes email. But this last restart has been running two weeks and the bridge DB shows no pool assignment.
Has anyone else experienced this? What's the remedy?
If it would help anyone figure this out I can post details, graphs, etc. along as they don't compromise the bridge. - eliaz
Hello! Unless something is broken, BridgeDB is still assigning your bridge to a distribution pool. However, if you're looking at your bridge in Atlas [0], then the "bridge pool assignment" field has been removed, and it should soon be removed from Globe [1] as well. See #13921. [2] [0]: https://atlas.torproject.org [1]: https://globe.torproject.org [2]: https://trac.torproject.org/projects/tor/ticket/13921 -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt
isis:
eliaz transcribed 0.9K bytes:
Can a bridge carry client traffic even though the bridge hasn't been assigned to a pool? [snip] As I recall, for previous restarts I've seen pool assignments within a few hours. [...] But this last restart has been running two weeks and the bridge DB shows no pool assignment. [snip] Unless something is broken, BridgeDB is still assigning your bridge to a distribution pool. However, if you're looking at your bridge in Atlas [0], then the "bridge pool assignment" field has been removed, > and it should soon be removed from Globe [1] as well. See #13921. [2]
Thanks for the heads up. It was interesting to see the assignments. But if (as I read the tickets), deleting it in globe & atlas makes the DB programmers'/maintainers' lives easier, I guess bridge operators can do without. However, I get a Not Found error for https://collector.torproject.org/recent/bridge-pool-assignments/ . Is this down temporarily, or permanently? - eliaz
[0]: https://atlas.torproject.org [1]: https://globe.torproject.org [2]: https://trac.torproject.org/projects/tor/ticket/13921
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27/12/14 04:03, eliaz wrote:
isis:
eliaz transcribed 0.9K bytes:
Can a bridge carry client traffic even though the bridge hasn't been assigned to a pool? [snip] As I recall, for previous restarts I've seen pool assignments within a few hours. [...] But this last restart has been running two weeks and the bridge DB shows no pool assignment. [snip] Unless something is broken, BridgeDB is still assigning your bridge to a distribution pool. However, if you're looking at your bridge in Atlas [0], then the "bridge pool assignment" field has been removed, > and it should soon be removed from Globe [1] as well. See #13921. [2]
Thanks for the heads up. It was interesting to see the assignments. But if (as I read the tickets), deleting it in globe & atlas makes the DB programmers'/maintainers' lives easier, I guess bridge operators can do without.
However, I get a Not Found error for
https://collector.torproject.org/recent/bridge-pool-assignments/ .
Is this down temporarily, or permanently? - eliaz
It's removed permanently. Should it return something else than Not Found? (I found 410 Gone as alternative, but have no idea how common that is.) All the best, Karsten
[0]: https://atlas.torproject.org [1]: https://globe.torproject.org [2]: https://trac.torproject.org/projects/tor/ticket/13921
_______________________________________________ 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 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJUnux9AAoJEJd5OEYhk8hIu5cIAIm500LhACJ5nuaRXFXKu+Ds ZBSmtKOnDTY3elu7vnOfVWEI6l0l1z6mjAh51rfraGp9v5tUJSbWXldM7NebNjFS gsJgaJgIdyUTtwI7beMJ4fprtKLcgZ+aDe0GKGCElspraQL3g5hQ3OjqmK/nDM93 ba9tjc5uMw+osr+JCiK+QSnCK9CPlqsXiHVhK0+n0dwJHb8m/TL/cyaLhy82QQ+e 5IsSAeAn3FYgFZalF9D/Ce+i3HzkG1QRWcLDUxOs5CgCzwCFxWTjW852SdUpq4ZL yL528hGiQqvxrotLj2OXAMr9m0SXpGPQf3lvH2c1Y9eisJIUpE7x3IcnSYquJi8= =IqgW -----END PGP SIGNATURE-----
Karsten Loesing:
On 27/12/14 04:03, eliaz wrote:
isis:
Can a bridge carry client traffic even though the bridge hasn't been assigned to a pool? [snip] As I recall, for previous restarts I've seen pool assignments within a few hours. [...] But this last restart has been running two weeks and the bridge DB shows no pool assignment. [snip] Unless something is broken, BridgeDB is still assigning your bridge to a distribution pool. However, if you're looking at your bridge in Atlas [0], then the "bridge pool assignment" field has been removed, and it should soon be removed from Globe [1] as well. See #13921.[2]
Thanks for the heads up. It was interesting to see the assignments. But if (as I read the tickets), deleting it in globe & atlas makes the DB programmers'/maintainers' lives easier, I guess bridge operators can do without.
However, I get a Not Found error for
https://collector.torproject.org/recent/bridge-pool-assignments/ .
Is this down temporarily, or permanently? - eliaz
It's removed permanently. Should it return something else than Not Found? (I found 410 Gone as alternative, but have no idea how common that is.)
The 404 is fine. I wasn't complaining about the error code, but rather inquiring about the future status of that bridge DB output. Knowing that it's gone deliberately & forever avoids a lot of puzzlement. I hope that as the outputs continue to change, someone finds the time to rewrite https://collector.torproject.org/formats.html#bridge-descriptors . While things are in process, it would suffice to write above defunct items something like "The following <item> has been permanently|temporarily|whatever disabled as of ddmmyy" Please take pity on the bridge operators! - eliaz
[0]: https://atlas.torproject.org [1]: https://globe.torproject.org [2]: https://trac.torproject.org/projects/tor/ticket/13921
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/12/14 04:06, eliaz wrote:
Karsten Loesing:
On 27/12/14 04:03, eliaz wrote:
isis:
Can a bridge carry client traffic even though the bridge hasn't been assigned to a pool? [snip] As I recall, for previous restarts I've seen pool assignments within a few hours. [...] But this last restart has been running two weeks and the bridge DB shows no pool assignment. [snip] Unless something is broken, BridgeDB is still assigning your bridge to a distribution pool. However, if you're looking at your bridge in Atlas [0], then the "bridge pool assignment" field has been removed, and it should soon be removed from Globe [1] as well. See #13921.[2]
Thanks for the heads up. It was interesting to see the assignments. But if (as I read the tickets), deleting it in globe & atlas makes the DB programmers'/maintainers' lives easier, I guess bridge operators can do without.
However, I get a Not Found error for
https://collector.torproject.org/recent/bridge-pool-assignments/ .
Is this down temporarily, or permanently? - eliaz
It's removed permanently. Should it return something else than Not Found? (I found 410 Gone as alternative, but have no idea how common that is.)
The 404 is fine. I wasn't complaining about the error code, but rather inquiring about the future status of that bridge DB output. Knowing that it's gone deliberately & forever avoids a lot of puzzlement. I hope that as the outputs continue to change, someone finds the time to rewrite
https://collector.torproject.org/formats.html#bridge-descriptors .
While things are in process, it would suffice to write above defunct items something like "The following <item> has been permanently|temporarily|whatever disabled as of ddmmyy" Please take pity on the bridge operators! - eliaz
Good idea, added a note and removed the "recent" link: https://collector.torproject.org/formats.html#bridge-pool-assignments All the best, Karsten
[0]: https://atlas.torproject.org [1]: https://globe.torproject.org [2]: https://trac.torproject.org/projects/tor/ticket/13921 _______________________________________________ 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 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJUn+JmAAoJEJd5OEYhk8hI11UIAK0E7Bk/9VbdIvAxbhK9Bwny 9EnjPwxikN55xALz40q4Tgc7Lq+nKO5crgX1+2z1r6uHPhZltJ2a9oPfWpEDhvAn OfZKJB8mQQ1eCxjR0d9riOQj7M4nAQIrzPYETSUoNZO6M7wIsDghNkJ/I8LbrKpM wP9OcJgMw0qXT86+urDO6X7Oe554OexdwFnJGJnVcrAR6srF479trE4J9bGHn01Z Zul0+96PTSeXuzhIELatbyn+SJ035sByK0PkiLtgJpSBWuEmmnzqwRW7dwz3k4aG hhfdT+uVfcMebhJfNIPrgIyJ5A6vQMGRyiRp4WxbzF+RNGbBDNn4rK2yD75OsDg= =6huT -----END PGP SIGNATURE-----
participants (6)
-
eliaz -
isis -
Karsten Loesing -
Moritz Bartl -
s7r -
Sebastian Urbach