I'm running the relay https://globe.torproject.org/#/relay/18EAAF7CB6C2ABE8583841D305C06A509F8C1C8... and am getting substantially lower rates than expected after almost 3 months. I'm on a 1Gbps down/1Gbps up line but my middle relay is just barely creeping upwards of 5Mbps. This is NOT a problem of less bandwidth after receiving the guard flag, and I have read the lifecycle of a new relay documentation. I cannot find the bottleneck in my setup and was wondering if there are any good tools I could use to find where it is. I've read https://www.torservers.net/wiki/setup/server and https://wiki.archlinux.org/index.php/tor for tips on speeding things up, but nothing has proven successful. Things I have considered: CPU usage: hovers around 5-10%, using NumCPUs 2 Mem usage: 195 MB (10%), using DisableAllSwap 1 Using AvoidDiskWrites 1 to avoid SSD stress Rate/Burst limits at 20MB (160mbps) Using dd if=/dev/urandom of=rand bs=64M count=16 iflag=fullblock to create a 1GB file I test copying this file to/from another machine on my LAN using scp 100% 1024MB 28.4MB/s 00:36 to copy to the relay (307 Mbps) 100% 1024MB 53.9MB/s 00:19 to download from the relay (431.2 Mbps) Okay so not full 1Gbps speeds, but still an order of magnitude higher than the 5Mbps my relay is using, so the problem doesn't look like it is the router or gigabit switch on my LAN. I've also raised the maximum number of open file descriptors for the debian-tor user. In /etc/security/limits.conf I added debian-tor soft nofile 65000 debian-tor hard nofile 65000 I'm not sure if this worked because (even after reboot) sudo -u debian-tor bash ulimit -Hn returns 4096. I would say that is the problem, but looking in /proc/torPID/fd and doing ls -l | wc -l returns 1591, so I'm not hitting the limit of 4096. In any case, if you know why my limits.conf doesn't appear to have taken effect, let me know. I've also added other optimizations from the torservers wiki. My /etc/sysctl.conf is http://paste.debian.net/162765/ Thanks for the help, James Murphy
James,
I've also raised the maximum number of open file descriptors for the debian-tor user. In /etc/security/limits.conf I added debian-tor soft nofile 65000 debian-tor hard nofile 65000 I'm not sure if this worked because (even after reboot) sudo -u debian-tor bash ulimit -Hn returns 4096.
I'm currently not in front of a Debian box but I believe you will need to change the pam.d configuration, the limits module is imho not loaded in the su(do) configuration. Renke
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 renke brausse:
James,
I've also raised the maximum number of open file descriptors for the debian-tor user. In /etc/security/limits.conf I added debian-tor soft nofile 65000 debian-tor hard nofile 65000 I'm not sure if this worked because (even after reboot) sudo -u debian-tor bash ulimit -Hn returns 4096.
I'm currently not in front of a Debian box but I believe you will need to change the pam.d configuration, the limits module is imho not loaded in the su(do) configuration.
James, if you use the default init.d script that comes with torproject's tor package you shouldn't have to worry about file descriptors. You can verify it via grep open /proc/<tor pid>/limits I see you are only running a single tor instance. If you are on a GBit/s link you certainly want to run more than one instance. The 3 months graph on atlas show a steady grow in used bw, so it looks like it will continue that way. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVEEy9AAoJEFv7XvVCELh02J8P/28fEEyZyNozUNVZ11S2SVI5 LUQ9tBd5+bJdk4AsCFxu+OFkes+uI+uvaA0jb0i8xX0epS6gr42sLa4deBd1USH2 gyUBQYNu9ejSfl2xrWnxNDM19UJTqw59QcfwIuwObjiP5YEma0CQ9VbK5CBP6N9H wJI0berlhchY0k31BqrwDVMHSkbxTbVd9dYNkQ1So6VnOqoi5vkt4oFAlWNzvMLL vpgPrFMr+JKVIDVXM8CYt16oYc0EfatKmuNgaMsrF2zAGoZXHaTuoeeWcPZqHGKq T7/EzlhjNsKYaVoINeitgG1EaRqPeHe0QRx8+fjPxorJMGMdtOI69sMk5HNwSkql X01BgNhwhizpQBoi1fmwHipbIppMBEPqwBdKPeUTuTl9RyJ9uD6kJG5w1JqZx1eB AvuRzgLK/JLKH8LzsYI4FKfnzg08RWPk6XmfDF218LWFzXV9kYVf6/KtnfEa+mnp RV5jxyh0asuGxnl2xQBNt0Bn48kM8xvNAZGfmlivW+j/tHTolSAHj7LoUJfpodxj vC+mFY3Swq772EBZ4mdZwAVEy1LGMMaIMMAuLVIv1Y67lmon+p6xvpglhRWZNJyF yYWy0kxjIAj0qW9AOBB9Q0cxvrZQ70gxcsfVWpSimhs6Y1QwJGvYi8BnMieiF0CE 9WdLPL1OO/mXGTxtTAHl =zLbh -----END PGP SIGNATURE-----
On 03/23/2015 05:38 PM, James Murphy wrote:
dd if=/dev/urandom of=rand bs=64M count=16 iflag=fullblock to create a 1GB file I test copying this file to/from another machine on my LAN using scp
This is LAN, not Internet. Are you sure you have more than 5 Mbps in upstream bandwidth? I am not aware of any AT&T offers that have full Gbit. -- Moritz Bartl https://www.torservers.net/
On 03/23/2015 10:52 PM, Patrick R McDonald wrote:
On Mon, Mar 23, 2015 at 10:36:34PM +0100, Moritz Bartl wrote:
This is LAN, not Internet. Are you sure you have more than 5 Mbps in upstream bandwidth? I am not aware of any AT&T offers that have full Gbit. AT&T does offer 1GB fiber in the Kansas City area.
That is downstream; upstream, from what I read, is "up to 300 Mbps". Up to. -- Moritz Bartl https://www.torservers.net/
https://www.att.com/shop/u-verse/gigapower.html In Austin we have Gigapower, "1Gbps" up and down. I should have mentioned, using speedtest-cli I can measure about 450 down, 100 up. With AT&T's proprietary "speed test" I can "measure" 1Gbps both directions. I don't really believe those numbers, but for sure speedtest-cli can measure 100 up. Still much higher than the 5Mbps my relay is seeing. Note: the slow speeds from speedtest-cli could be because AT&T is lying about my speed, but it could also be that none of the speedtest-cli servers are reachable entirely through fiber (i.e. through bad luck I get routed through a slow middleman on my way to the speed test server). On 03/23/2015 05:02 PM, Moritz Bartl wrote:
On 03/23/2015 10:52 PM, Patrick R McDonald wrote:
On Mon, Mar 23, 2015 at 10:36:34PM +0100, Moritz Bartl wrote:
This is LAN, not Internet. Are you sure you have more than 5 Mbps in upstream bandwidth? I am not aware of any AT&T offers that have full Gbit. AT&T does offer 1GB fiber in the Kansas City area. That is downstream; upstream, from what I read, is "up to 300 Mbps". Up to.
participants (5)
-
James Murphy -
Moritz Bartl -
Nusenu -
Patrick R McDonald -
renke brausse