Opened 8 years ago

Closed 6 years ago

#4249 closed defect (worksforme)

Tor not respecting bandwidth limits

Reported by: funkstar Owned by:
Priority: Medium Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version: Tor: 0.2.3.12-alpha
Severity: Keywords: tor-bridge bandwidth
Cc: opensource@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I've selected a bandwidth limit of 512kbps in Vidalia and my upload is 800kbps. But Tor doesn't seem to respect this setting. If I look at the map in Vidalia I'm sometimes reported as much higher (64kBps). How can I stop Tor from sapping my entire upload pipe?

Child Tickets

Change History (35)

comment:1 Changed 8 years ago by arma

What bundle did you install?

Are you a relay, or are you using your Tor as a client? (or both?) If a relay, what's the nickname?

Note that 64kBps is the same as 512kbps. I worry that you're multiplying or dividing, or not, by 8 somewhere.

comment:2 Changed 8 years ago by Sebastian

Component: - Select a componentTor Client

putting this into tor client for now so it doesn't get completely lost in the noise

comment:3 Changed 8 years ago by Sebastian

Status: newneeds_information

comment:4 Changed 8 years ago by funkstar

I've installed the unstable Vidalia bundle and I'm set up as an exit, only accepting http/https websites.

The 512kbps option is selected, but even spectating the bandwidth graph I've seen it say "101kBps" as a momentary upload spike (which isn't possible) but gives the impression that it isn't quite respecting the limits.

Does the limit include overhead? Is it possible the remaining ~20kB is being used by TCP overhead? I can try using a custom limit and lower it ever more but I'm afraid of rendering it useless for not allocating enough upload.

comment:5 Changed 8 years ago by funkstar

Relay is funkstar if on at time of reading.

comment:6 Changed 8 years ago by Sebastian

When you select 512kbps in Vidalia, it configures your Tor client with a 512kbps long-term limit and a burst of up to twice that much, which means that for short periods of time Tor can go over the limit. Vidalia doesn't currently allow finer-grained control for a separate value.

Also note that Vidalia only sets the RelayBandwidthRate and RelayBandwidthBurst options, so if you are using tor as a client and also provide a relay, only the relay traffic is affected by the bandwidth limit.

It seems like you want to add this to your torrc file:
BandwidthRate 64KB
BandwidthBurst 64KB

to be on the safe side.

comment:7 Changed 8 years ago by funkstar

Thanks I'll try that. No I'm only using Tor to donate my bandwidth as an exit note, I don't actually use Tor myself for browsing, but the issue here was with the overall slowness of websites *I* browse because of Tor using all my upload.

To be fair I picked websites only as an exit rule for a reason, as I don't have the greatest of upload speeds and browsing/blogging/etc isn't exactly intensive work, so I could make a reasonable contribution in that regard. Watching the bandwidth graph confirms this, a lot of the time no upload is used, then it will "bump" as if to state websites are being browsed/loaded. What I failed to think of is that downloads are probably also counted as the same exit policy which pretty much uses the entire upload allocation for a protracted period of time, unlike simply browsing a page.

Can I edit that file and add those settings without restarting the relay?

comment:8 in reply to:  7 Changed 8 years ago by rransom

Replying to funkstar:

Can I edit that file and add those settings without restarting the relay?

Yes, but it's a PITA on Windows.

If you have a recent version of Vidalia, there should be an ‘Edit current torrc’ button somewhere in the ‘Settings’ dialog. Use that instead.

comment:9 Changed 8 years ago by funkstar

Thanks, it reveals this:
RelayBandwidthBurst 131072
RelayBandwidthRate 65536
which probably explains it. I'll drop it to about 55000 and 65000 respectively.

On a side note, is this correct for http & https websites?
ExitPolicy accept *:80,accept *:443,reject *:*

I assume there's no way to separate HTTP downloads from browsing.

comment:10 in reply to:  9 Changed 8 years ago by rransom

Component: Tor ClientVidalia
Owner: set to chiiph
Status: needs_informationassigned
Summary: Tor not respecting bandwidth limitVidalia sets RelayBandwidthBurst to 2*RelayBandwidthRate

Replying to funkstar:

Thanks, it reveals this:
RelayBandwidthBurst 131072
RelayBandwidthRate 65536
which probably explains it. I'll drop it to about 55000 and 65000 respectively.

RelayBandwidthBurst should always be greater than or equal to RelayBandwidthRate.

On a side note, is this correct for http & https websites?
ExitPolicy accept *:80,accept *:443,reject *:*

Yes.

I assume there's no way to separate HTTP downloads from browsing.

There are ways to distinguish the two activities, but Tor exit policies will never be able to support them.

Do we want to change the behaviour of Vidalia's settings GUI here (always setting RelayBandwidthBurst to 2*(value of RelayBandwidthRate))?

comment:11 Changed 8 years ago by funkstar

Currently Vidalia only has an "average rate" and "maximum rate" when selecting the custom field, there might warrant a need to have a little description/details as to what these settings are. E.g. "average rate" is actually your "standard maximum rate" and "maximum rate" is your "burst rate".

When using a speed pre-set there is only one box and no indicator that the burst rate will be twice of that (what happened to me).

Ideally something like this:
"The average rate is the speed that Tor will usually function at:"
box-to-enter-average-rate-here
"Tor will sometimes burst to a higher speed than usual, this is limited by the maximum rate. This should ideally be higher than your average rate, but lower than your maximum upload connection speed:"
box-to-enter-burst-speed-here

comment:12 Changed 8 years ago by funkstar

I should have added that when you select a speed pre-set you naturally assume this will be the max speed and set it at your connection speed or lower. So having a burst speed of higher than that could be considered flawed in that regard.

comment:13 Changed 8 years ago by funkstar

I don't know if this is of significance but I've got my rates set to 55000 and 57000 which is about 53KB and 55KB according to Vidalia. Unfortunately after spectating the Vidalia bandwidth graph I have seen it "spike" as high as 96KBps.

I don't know if this is just an inaccuracy or not, as this spike only lasts 1 update. E.g. Graph update > 20kBps, graph update > 96kBps, graph update > 48kBps.

http://img444.imageshack.us/img444/6277/spikez.png

comment:14 Changed 8 years ago by funkstar

Any comments?

comment:15 Changed 8 years ago by funkstar

bump

comment:16 Changed 8 years ago by funkstar

bump :(

comment:17 Changed 8 years ago by chiiph

I think that if you use the presets then there a high probability that you aren't exactly sure what you are setting, and talking about "bursts" might make people more confused. So I think it's reasonable to make use *2 for the burst.

OTOH, if you are using custom, Vidalia doesn't manipulate the numbers you specify in the text edits other than doing a *1024 to specify bytes instead of kilobytes when passing them to Tor. So if this is the case, this might be a bug in Tor (unless I'm missing something here).

comment:18 Changed 8 years ago by funkstar

Not sure where we go from here, the "spiking" issue I described still exists in Tor.

comment:19 Changed 8 years ago by funkstar

Component: VidaliaTor Bridge
Owner: chiiph deleted
Summary: Vidalia sets RelayBandwidthBurst to 2*RelayBandwidthRateTor not respecting bandwidth limits
Version: Tor: 0.2.3.5-alphaTor: 0.2.3.12-alpha

This is still a major pain in the ass. I'm now running a Tor bridge for censored users instead of an exit relay and still have these issues. I've set the average to 52 and maximum to 58 but I still get period spikes (Vidalia graph reads 95kbps!?!?) which can last a few seconds, making gaming at the same time a nightmare.

comment:20 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-final

comment:21 Changed 7 years ago by funkstar

Was this fixed in the latest alpha? I think I saw something in the changelog, haven't been able to try it yet.

comment:22 Changed 7 years ago by nickm

I don't know anything in the most recent rc that is sure to have fixed this, but there have been a few small changes in this general area.

I've been trying to reproduce the issue on and off, but so far I've had no luck there. Are you running obfsproxy on your bridge by any chance?

comment:23 Changed 7 years ago by funkstar

I believe this was before obfsproxy was even available, but no I'm not running it. I haven't ran Tor in several months as I cannot acquire the latest version (https://trac.torproject.org/projects/tor/ticket/6142) so I cannot test if this has changed.

comment:24 Changed 7 years ago by nickm

Keywords: tor-bridge added

comment:25 Changed 7 years ago by nickm

Component: Tor BridgeTor

comment:26 Changed 7 years ago by joergent

Keywords: bandwidth added

I am also having the problem with a relay on a non-dedicated line (Tor 0.2.2.39 (git-bec76476efb71549)) and to such an extent, that we have stopped running the relay node.

RelayBandwidthBurst 65536
RelayBandwidthRate 32768

(from selecting a predefined value in Vidalia)
has no apparent effect. The Vidalia bandwidth meter is displaying values of 100-300 Kb/s for extended periods of time.

Whether very many of these error messages in the log (30/s) is a part of it. I don't know (DOS attempt ?):

okt 03 21:58:04.171 [Warning] Socks version 67 not recognized. (Tor is not an http proxy.)

comment:27 Changed 7 years ago by joergent

Cc: opensource@… added

comment:28 in reply to:  26 ; Changed 7 years ago by arma

Replying to joergent:

I am also having the problem with a relay on a non-dedicated line (Tor 0.2.2.39 (git-bec76476efb71549)) and to such an extent, that we have stopped running the relay node.

RelayBandwidthBurst 65536
RelayBandwidthRate 32768

(from selecting a predefined value in Vidalia)
has no apparent effect. The Vidalia bandwidth meter is displaying values of 100-300 Kb/s for extended periods of time.

Whether very many of these error messages in the log (30/s) is a part of it. I don't know (DOS attempt ?):

okt 03 21:58:04.171 [Warning] Socks version 67 not recognized. (Tor is not an http proxy.)

It's possible your issues are different. It sounds like you might have applications using Tor as a client -- the "relaybandwidthrate" does not attempt to restrict bandwidth for client applications, since we assume you want Tor to work as well as possible. It also doesn't attempt to restrict bandwidth used for directory fetches, etc.

So, what is this application that's trying to use Tor as a client for you?

comment:29 in reply to:  28 ; Changed 7 years ago by joergent

Replying to arma:

So, what is this application that's trying to use Tor as a client for you?

There are absolutely no clients using this relay. It is a rather vanilla Linux server.

comment:30 in reply to:  29 Changed 7 years ago by arma

Replying to joergent:

Replying to arma:

So, what is this application that's trying to use Tor as a client for you?

There are absolutely no clients using this relay. It is a rather vanilla Linux server.

What is connecting to your socks port 30 times a second then?

comment:31 Changed 7 years ago by joergent

External IPs are connecting to the SOCKS port even if it always has been restricted to the local network. I don't know why. In Tor 0.2.3.22-rc this is causing 100% CPU usage (sic!) as opposed to 0.2.2.39. When disabling access to the SOCKS port from the Internet in the firewall the CPU usage is reduced to 1 digit figures.

Vidalia 0.2.20 is having trouble in connecting beyond the Connected to the Tor network! message but eventually diplays the onion, so the Bandwidth Graph is functional.

It appears, that the bandwidth limiting is working in 0.2.3.22-rc, but the 100% CPU usage is a problem, as this was not so in 0.2.2.39

comment:32 Changed 6 years ago by arma

How is this in Tor 0.2.3 milestone?

I assume the issue is exactly the one that rransom changed the ticket to. But then the original poster changed it back?

comment:33 Changed 6 years ago by joergent

If only it had been a simple malconfiguration, but no. However, after using the Fedora 0.2.3.25-1802.fc18 package (with my old configuration) I have not detected similar problems.

comment:34 Changed 6 years ago by arma

I wonder if we should close this ticket since it is just a mess of user reports that never got sorted out. There are at least two user support questions going on. The original ticket was "Vidalia doesn't tell Tor to set its bandwidth in the way I expect", which is a fine real bug except now Vidalia is dead.

comment:35 Changed 6 years ago by nickm

Resolution: worksforme
Status: assignedclosed

I concur.

Note: See TracTickets for help on using tickets.