-----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
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
-----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
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.
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
_______________________________________________ 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:
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
-----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
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
tor-relays@lists.torproject.org
-
eliaz -
isis -
Karsten Loesing -
Moritz Bartl -
s7r -
Sebastian Urbach