I'm new to running a Tor relay and started one about a month ago. I've got 50 Mbps dedicated to it and at first it climbed in traffic pretty steadily until it got to around 25-30 Mbps being used. Since then, it has declined steadily and is down to about 350 KBps now (yes, I'm keeping the units straight). My node is a single core VPS running 3.2GHz and with 1GB RAM. Currently, top shows tor as using about 15% of the memory. When it was churning out at the maximum rate it got to, the CPU was pretty hammered. I was considering allocating another core, but there is no need anymore as it is hovering around 7% usage. The server is running on Ubuntu 16.04.3 and I'm running 0.3.1.7 tor. Am I doing something wrong to result in the decrease in traffic? Any advice is appreciated. Trey Nolen
Hi, Trey Nolen wrote:
I'm new to running a Tor relay and started one about a month ago. I've got 50 Mbps dedicated to it and at first it climbed in traffic pretty steadily until it got to around 25-30 Mbps being used. Since then, it has declined steadily and is down to about 350 KBps now (yes, I'm keeping the units straight).
My node is a single core VPS running 3.2GHz and with 1GB RAM. Currently, top shows tor as using about 15% of the memory. When it was churning out at the maximum rate it got to, the CPU was pretty hammered. I was considering allocating another core, but there is no need anymore as it is hovering around 7% usage.
The server is running on Ubuntu 16.04.3 and I'm running 0.3.1.7 tor.
Am I doing something wrong to result in the decrease in traffic? Any advice is appreciated.
Trey Nolen
First of all, thanks for running a relay. Based on my experience, what usually happens is that the provider of your VPS observed during a period of time you used more than N mbps constantly and all the time, so they capped your VPS at some KB/s limit. There are performance monitoring scripts that could do this automatically. A virtual private server shares the network card of the host with the other VPSes on that host, so almost all providers do not allow you to use it all by yourself all the time for long periods. You can open a ticket upstream and they will confirm if this is the case or not. Nothing you can do about this unfortunately, most providers do this, even the ones they say they don't do it :) Only thing you can do is get a dedicated server with guaranteed bandwidth, or try to convince them to at least lift your the limitation for your VPS to 1mbps.
First of all, thanks for running a relay.
Based on my experience, what usually happens is that the provider of your VPS observed during a period of time you used more than N mbps constantly and all the time, so they capped your VPS at some KB/s limit. There are performance monitoring scripts that could do this automatically. A virtual private server shares the network card of the host with the other VPSes on that host, so almost all providers do not allow you to use it all by yourself all the time for long periods. You can open a ticket upstream and they will confirm if this is the case or not.
Nothing you can do about this unfortunately, most providers do this, even the ones they say they don't do it :) Only thing you can do is get a dedicated server with guaranteed bandwidth, or try to convince them to at least lift your the limitation for your VPS to 1mbps.
In this case, this is not going on as we *are* the provider. I'm a sysadmin on the network and I'm one of the guys that would be in charge of limiting any machines which violated any rules. :-) Trey Nolen
Trey Nolen wrote:
First of all, thanks for running a relay.
Based on my experience, what usually happens is that the provider of your VPS observed during a period of time you used more than N mbps constantly and all the time, so they capped your VPS at some KB/s limit. There are performance monitoring scripts that could do this automatically. A virtual private server shares the network card of the host with the other VPSes on that host, so almost all providers do not allow you to use it all by yourself all the time for long periods. You can open a ticket upstream and they will confirm if this is the case or not.
Nothing you can do about this unfortunately, most providers do this, even the ones they say they don't do it :) Only thing you can do is get a dedicated server with guaranteed bandwidth, or try to convince them to at least lift your the limitation for your VPS to 1mbps.
In this case, this is not going on as we *are* the provider. I'm a sysadmin on the network and I'm one of the guys that would be in charge of limiting any machines which violated any rules. :-)
Trey Nolen
Oh, OK. Glad to see not everybody who rents virtual private servers also caps their bandwidth. It happened to me so many times that I could even bet that this was the issue here, but looks like it's not. Since atlas is down, I have looked at the votes here: https://consensus-health.torproject.org/consensus-health.html and it looks like your relay has a measured by authority 'bastet' of 355. That is not a big value. The other authorities measured this: 278; 355; 367; 803; So it looks like the speed was pretty much the same for the measurements performed on your relay by different servers on different networks. If you say you are sure there is nothing automated (at either OS level, hypervisor level, local router/network level or something upstream) that could throttle this in case of continuous high usage, there's not much you can do other than waiting some time to see the next speed measurements.
On 24 Oct 2017, at 09:08, s7r <s7r@sky-ip.org> wrote:
it looks like your relay has a measured by authority 'bastet' of 355. That is not a big value. The other authorities measured this:
278; 355; 367; 803;
So it looks like the speed was pretty much the same for the measurements performed on your relay by different servers on different networks. If you say you are sure there is nothing automated (at either OS level, hypervisor level, local router/network level or something upstream) that could throttle this in case of continuous high usage
Your AS shows up as BellSouth.net, which redirects to AT&T. Have you asked them if they're throttling you? (Or do you work for BellSouth?)
there's not much you can do other than waiting some time to see the next speed measurements.
You can check the warning and notice level Tor logs to see the amount of traffic Tor thinks it is handling. You can also tap or mouse over the bandwidth in Atlas, and it will show you what's limiting your relay - in this case, it appears to be the consensus weight. (The observed maximum bandwidth is 2.44 MBps, and the rate and burst are 5 and 10 MBps.) Unfortunately, sometimes relays get stuck in a low measurement category. We're working on a test environment, so we can start fixing issues like this. In the meantime, you can try the following things: * restart the relay * change the IP address * delete all the relay keys and start again You might want to wait a week or so after trying each step. Please let us know if one of these things works, it will help us diagnose the issue. T
On 10/23/2017 6:12 PM, teor wrote:
On 24 Oct 2017, at 09:08, s7r <s7r@sky-ip.org> wrote:
it looks like your relay has a measured by authority 'bastet' of 355. That is not a big value. The other authorities measured this:
278; 355; 367; 803;
So it looks like the speed was pretty much the same for the measurements performed on your relay by different servers on different networks. If you say you are sure there is nothing automated (at either OS level, hypervisor level, local router/network level or something upstream) that could throttle this in case of continuous high usage Your AS shows up as BellSouth.net, which redirects to AT&T. Have you asked them if they're throttling you?
(Or do you work for BellSouth?)
there's not much you can do other than waiting some time to see the next speed measurements. You can check the warning and notice level Tor logs to see the amount of traffic Tor thinks it is handling.
You can also tap or mouse over the bandwidth in Atlas, and it will show you what's limiting your relay - in this case, it appears to be the consensus weight. (The observed maximum bandwidth is 2.44 MBps, and the rate and burst are 5 and 10 MBps.)
Unfortunately, sometimes relays get stuck in a low measurement category. We're working on a test environment, so we can start fixing issues like this.
In the meantime, you can try the following things: * restart the relay * change the IP address * delete all the relay keys and start again
You might want to wait a week or so after trying each step. Please let us know if one of these things works, it will help us diagnose the issue.
I've already restarted the relay (been about 5-6 days). It was doing this before the restart although it continues to decline. I'll delete the whole VPS and create a new one. LOL...guess I'll be starting new on my t-shirt authorization (but that is another thread...). Trey Nolen
I'm not trhotling VPS when renting them :) for real !! BTW is the atlas webserver running ? database backend problem ? https://atlas.torproject.org/#search/208.94.110.37 Le 2017-10-23 17:34, s7r a écrit :
Hi,
Trey Nolen wrote:
I'm new to running a Tor relay and started one about a month ago. I've got 50 Mbps dedicated to it and at first it climbed in traffic pretty steadily until it got to around 25-30 Mbps being used. Since then, it has declined steadily and is down to about 350 KBps now (yes, I'm keeping the units straight).
My node is a single core VPS running 3.2GHz and with 1GB RAM. Currently, top shows tor as using about 15% of the memory. When it was churning out at the maximum rate it got to, the CPU was pretty hammered. I was considering allocating another core, but there is no need anymore as it is hovering around 7% usage.
The server is running on Ubuntu 16.04.3 and I'm running 0.3.1.7 tor.
Am I doing something wrong to result in the decrease in traffic? Any advice is appreciated.
Trey Nolen
First of all, thanks for running a relay.
Based on my experience, what usually happens is that the provider of your VPS observed during a period of time you used more than N mbps constantly and all the time, so they capped your VPS at some KB/s limit. There are performance monitoring scripts that could do this automatically. A virtual private server shares the network card of the host with the other VPSes on that host, so almost all providers do not allow you to use it all by yourself all the time for long periods. You can open a ticket upstream and they will confirm if this is the case or not.
Nothing you can do about this unfortunately, most providers do this, even the ones they say they don't do it :) Only thing you can do is get a dedicated server with guaranteed bandwidth, or try to convince them to at least lift your the limitation for your VPS to 1mbps.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Stephane Thevenot:
BTW is the atlas webserver running ? database backend problem ?
onionoo (atlas backend) has currently some issues, the maintainer and admins are looking into it https://trac.torproject.org/projects/tor/ticket/23929 -- https://mastodon.social/@nusenu twitter: @nusenu_
Trey Nolen:
I'm new to running a Tor relay and started one about a month ago. I've got 50 Mbps dedicated to it and at first it climbed in traffic pretty steadily until it got to around 25-30 Mbps being used. Since then, it has declined steadily and is down to about 350 KBps now (yes, I'm keeping the units straight).
My node is a single core VPS running 3.2GHz and with 1GB RAM. Currently, top shows tor as using about 15% of the memory. When it was churning out at the maximum rate it got to, the CPU was pretty hammered. I was considering allocating another core, but there is no need anymore as it is hovering around 7% usage.
The server is running on Ubuntu 16.04.3 and I'm running 0.3.1.7 tor.
Am I doing something wrong to result in the decrease in traffic? Any advice is appreciated.
It is always good to include an atlas URL or fingerprint / IP to your relay when asking for help about a specific relay https://atlas.torproject.org/#details/2721B60067A1EF1DE7926BAADDCAD490AB5CAE... -- https://mastodon.social/@nusenu twitter: @nusenu_
On 10/23/2017 04:36 PM, nusenu wrote:
Trey Nolen:
I'm new to running a Tor relay and started one about a month ago. I've got 50 Mbps dedicated to it and at first it climbed in traffic pretty steadily until it got to around 25-30 Mbps being used. Since then, it has declined steadily and is down to about 350 KBps now (yes, I'm keeping the units straight).
My node is a single core VPS running 3.2GHz and with 1GB RAM. Currently, top shows tor as using about 15% of the memory. When it was churning out at the maximum rate it got to, the CPU was pretty hammered. I was considering allocating another core, but there is no need anymore as it is hovering around 7% usage.
The server is running on Ubuntu 16.04.3 and I'm running 0.3.1.7 tor.
Am I doing something wrong to result in the decrease in traffic? Any advice is appreciated. It is always good to include an atlas URL or fingerprint / IP to your relay when asking for help about a specific relay
https://atlas.torproject.org/#details/2721B60067A1EF1DE7926BAADDCAD490AB5CAE...
Thanks for the advice. For this particular one, the fingerprint is 2721 B600 67A1 EF1D E792 6BAA DDCA D490 AB5C AE36 Trey Nolen
50 Mbps 25-30 Mbps 350 KBps yes, I'm keeping the units straight
No not really. Crossing down away from megabits while still within reasonable single megabit range is awkward. And 'K' is not a valid prefix so no one knows whether you meant 1000 'k' or 1024 'Ki'. And '(B)ytes' is RAM and file storage context, while bits is usual context of real network attached applications / hardware / ISP, ie log into any real router [hw/sw], even bitttorrent and kernels are now starting to get this this right. Though bit/s is in iec80000-13, not bps... 2.8Mbps or 2800kbps, or ~2870kbps if your K was really Ki... is a much safer consistant contextual thing to say next time.
On 27 Oct 2017, at 07:41, grarpamp <grarpamp@gmail.com> wrote:
50 Mbps 25-30 Mbps 350 KBps yes, I'm keeping the units straight
No not really. Crossing down away from megabits while still within reasonable single megabit range is awkward. And 'K' is not a valid prefix so no one knows whether you meant 1000 'k' or 1024 'Ki'. And '(B)ytes' is RAM and file storage context, while bits is usual context of real network attached applications
The 2% difference isn't relevant in the context of a 100x drop in relay bandwidth. And posting two emails about minor unit differences doesn't help us resolve this issue. Please try to keep your emails on-topic, because every email to this list goes out to hundreds of people. T
On topic of relays is. Endeavouring to exchange information succinctly among parties without undue what guessing. As is if we have operators or readers where 'straight' belief would be both incorrect and operationally significant... such as getting slammed with unexpected overage bill based on 2% or other error, thus potentially leading to termination or inability to afford to continue relay service under limited funds budget. Same for such errors perhaps bumping up against committed rate limits potentially degrading packet delivery performance. ie: one potential error in such ways regarding a 1 Gbit/s, could result in a continuous ~73.8 Mbit/s too much traffic, and thus ~7.4% bill or packet problems including hard drops.
participants (6)
-
grarpamp -
nusenu -
s7r -
Stephane Thevenot -
teor -
Trey Nolen