Transmission BitTorrent doesn't honor speed limitation preferences

[Lonnie Lee Best]

Binary package hint: transmission

I've set the download AND upload speeds to 10 KB/s, and (unexpectedly) Transmission continues to allow download speeds of 75 KB/s or more.

My Uncle is trying to watch some streaming video off of the Internet, right now, and because Transmission won't honor the speed limitations I specified in its preferences menu, I'm having to turn off Transmission altogether until he's done with his on-line video watching.

ProblemType: Bug
Architecture: i386
Date: Sun Oct 25 18:24:51 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/transmission
Package: transmission-gtk 1.75-0ubuntu2
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: transmission
Uname: Linux 2.6.31-14-generic i686

[Charles Kerr (charlesk)]

Thank you for taking the time to report this and helping to make Ubuntu better.

I've known Transmission to fluctuate above the speed limit for a brief period, and don't consider that to be a serious bug. But if you're getting =sustained= 75 KB/s or more when the speed limit is set to 10 KB/s then that would be a problem.

Things to check:

* Are "alternative" speeds turned on? (Is the turtle icon lit?) If so, what are there settings?
* Do you have any per-torrent speeds set? Are any of them set to ignore the global limits? (See the Properties -> Options dialog for each torrent)
* When Transmission goes up to 75 KB/s, is it for a moment or two, for 10 seconds or more, or is it a constant, sustained speed?

[Lonnie Lee Best (launchpad-startport)]

It is indeed sustained; it never reaches anything close to the limitations I've set. This was a very large collection, could that be relevant? Sometimes extremes aren't anticipated while coding.

Call me if you need me to test something:
http://www.lonniebest.com/Phone/

[Charles Kerr (charlesk)]

Okay that answers the third question.. and the first two?

Also, how many torrents are you running at once? If multiple torrents, Is the speed all coming from one or two of them, or is it spread out across all of them?

[Everthon Valadão (valadao)]

Same here: usually the global max upload speed isn't respected at all. I have to set they to about half the desired value to get something slightly close to what I want.

R1) The alternative speeds are turned off, but, anyway, they are configured exactly the same as the global speeds;
R2) All my torrents are configured to "honor the global limits", so no per torrent speeds (and I have something about 3-5 simultaneous downloads)
R3) Transmission usually fluctuates *high above* the global max speeds, with an average of 1.5-2.0 times the global max speeds, specially for upload speeds.

I tried to perform some traffic shaping via trickle but I had no success (i.e. `trickle -d 50 -u 10 transmission`).
BTW, rtorrent religiously respect the global max speeds and this is why I prefer it over transmission nowadays.

[Charles Kerr (charlesk)]

I can't reproduce this behavior and am not sure how to proceed on this ticket.

[Everthon Valadão (valadao)]

@charles, try this:

- open Transmission and set the max download and upload speeds to half your network capabilities;
- then add some torrents (e.g. ubuntu-9.10 i386, amd64 and remix releases);
- watch the network usage with the "System Monitor" and the alleged speed at Transmission status bar

You will notice that the consumption will far exceed the limits you configured, specially for the upload.

[Strecker (holmgangskeggi)]

The upload limit is set to 5 KB/s currently, but Transmission still sends with 105 KB/s. All torrents are set to honor the global settings and the temporary limits are off. It really doesn't matter what settings I use. It always uses my full upload capacity. This way I'm never able to seed for long.

[Charles Kerr (charlesk)]

Sorry for taking so long to respond to this.

In the time that's passed, the Lucid pre-releases now ship with a beta version of Transmission 1.80. Does this problem still persist in Transmission 1.80?

[Charles Kerr (charlesk)]

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

[Lonnie Lee Best (launchpad-startport)]

Perhaps the confusion arises from the UI. Intuitively, it doesn't make a clear separation between "when you are rate limiting globally" and "when you are rate limiting granularly".

This confusion leads to the user, thinking they have limited the global rate, when they've actually limited the rate of a particular download. See Vuze. They have a global rate limiter in the bottom-right corner. To limit on a file basis, it requires clicking on that file. That's more intuitive and should be emulated in my opinion. I'm still using vuze, but I may switch soon.

Mainly, it need to be abundantly clear whether you are "limiting globally" or "limiting granularly", while your are doing it. Until this is more clear, I suspect you'll have additional bug reports due to this confusion. This is usability bug.

[Charles Kerr (charlesk)]

I don't understand what you mean when you quote the phrase "limiting granularly". Transmission doesn't use that terminology anywhere. Are you referring to the per-torrent speed limits?

[Everthon Valadão (valadao)]

I'm afraid it's not an UI problem, but a *resource management* problem:

It's very simple to verify: set your max global upload speed to X KB/s, then seed something and when Transmission status bar show X KB/s upload speed, check at the Ubuntu "System Monitor" or conky or /proc/whatever and you will realize that transmission isn't uploading at X KB/s but at something close to 2X KB/s!

So, transmission doesn't honor the (global) speed limits.

[Everthon Valadão (valadao)]

BTW, I'm using Ubuntu 9.10 with Transmission 1.75 (9117) and previous versions also had this issue.

$ cat /etc/issue
Ubuntu 9.10

$ uname -a
Linux valadao-desktop 2.6.31-20-generic #57-Ubuntu SMP Mon Feb 8 09:02:26 UTC 2010 x86_64 GNU/Linux

$ apt-cache policy transmission-gtk
transmission-gtk:
  Installed: 1.75-0ubuntu2.2
  Candidate: 1.75-0ubuntu2.2

[Vish (vish)]

I'm using Transmission 1.90 (10221) in Lucid.

I find this bug very difficult to use transmission :(
If transmission is running, browsing the web becomes very difficult.I have to shutdown the torrent or transmission completely.

How I'v configured transmission is:
- Global Upload and download speeds : 15kb/s : 5kb/s
- I download only on torrent at a time and i find the problem more with torrents with good number of seeds.
- limited speed are at 5kb/s : 5kb/s

Why I'm having to set these so low is ,since the speed limits are never honored for the good torrents...

The partial workaround for now is to go in the torrent properties and set the speed limit for each torrent but that works only a few times , and that too isnt very effective always.

Note however , that transmission window in the list shows the limits are being used but the speed reading from the conky/system monitor and the inability to web browsing indicate the speeds are being maxed out.

Attaching screenshots.

[David Nielsen (davidnielsen-deactivatedaccount)]

I set te limit at 47 kb/s upload, however currently it is happily going at 100-150 kb/s with 20 torrents. The same thing happened with 3 torrents. It has only started happening in Lucid since the 1.90 upgrade. The version released to fix the ratio bug was fine.

[David Nielsen (davidnielsen-deactivatedaccount)]

It seems to honor the global limit but not the time constrained limits. Perhaps it is getting wrong time data or ignoring it?

[David Nielsen (davidnielsen-deactivatedaccount)]

Could be:
http://trac.transmissionbt.com/ticket/2907

which is fixed in the 1.9.1 release

[Charles Kerr (charlesk)]

Upstream ticket 2907 is not the same issue as this ticket.

[Lonnie Lee Best (launchpad-startport)]

Charles, yes, by "limiting granularly", I'm talking about limiting speed for a particular torrent instead of the limiting speed for all torrents globally. Transmission's interface isn't intuitive regarding this distinction. One thinks they are limiting globally, when they are actually limiting particular torrent's bandwidth only. Then, when they monitor their bandwidth globally, they think Transmission isn't honoring their settings. See vuze, for an interface that makes a clearer distinction for this.

[Charles Kerr (charlesk)]

Under Preferences > Speed, you can set the global speed limits.

Under Torrent > Preferences, you get a dialog with the torrent's name in the titlebar, and an Options tab that gives you a checkbox "[x] Honor global limits".

What is the source of confusion? This seems straightforward.

[Vish (vish)]

I'm not sure , why/what Lonnie is confused about the wording there. I dont see any confusion there.

But the problems still remains that transmission does not control the speed according to set limits.

[las (bandara-ls)]

I confirm bug is still there.clicking that turtle nor setting it by star icon doesnt work

[Vish (vish)]

Sadly due to this bug i had to switch back to vuze :(
Transmission is great with memory but when I set the limit to 15KB/s , it never controls speed.
Hope this bug is fixed soon.

[Dvanzo (danielvanzo)]

I can confirm this bug. Ubuntu 9.10, Transmission 1.75. See the attached image... Transmission show to you uploading at 10 KB/s but it's uploading at 30 KB/s...

Regards,

[Daniel Lee (longinus00)]

The amount your computer uploads and the amount transmission uploads are not strictly related. Transmission doesn't take into overhead when limiting upload speed. Your transfers will incur some overhead due to the bittorrent protocol and potentially DHT. If you're doing something else on the internet, say watching youtube, there will be further overhead that is completely outside of transmission's control.

Unless somebody can show definitively that transmission is not honoring its own speed limits then I think this should probably be marked invalid.

[Charles Kerr (charlesk)]

Daniel Lee's comment is right on the money.

[Vish (vish)]

@charles : It is sad to see this bug is being hand-waived without actually giving us steps to debug the issue. and saying that the user needs to prove it is transmissions fault!
why dont you try to give us some steps to debug this issue? and then tell us its not transmission's fault!

there are screenshots of users facing the problem that is the info *we* can provide.
If we knew about torrent protocols and if we knew how to debug, wouldnt we let you know already?

The problem here is not the over-head , but why isnt transmission trying to control the overhead even when we explicitly set the global limits?? [comment #15]
Then what is the purpose of having a global limit if it cannot control global transfer?
How are other clients able to control this global transfer[including over-head] too?
Vuze does this very well, if we set a global limit then it *is* honored.

If transmission devs dont want to fix the issue, it's up to you folk.
But mentioning it as an invalid bug is wrong. This bug is *not* invalid.
We are facing the bug and we have provided the info we can. The bug is valid. Not fixing it is upto you.. :-)
No debug info was requested , so not incomplete.
It's a wont fix rather. Its just lack of interest in debugging from the transmission devs.
Setting as wontfix instead since the intent[comment #27] seems to just close this bug.

[Charles Kerr (charlesk)]

Daniel Lee gave an intelligent explanation about why the amount of piece data being transferred isn't the same as the overall network footprint, and you dismissed this as "hand waving."

So I've spent the last 45 minutes doing snapshots of different BitTorrent clients to demonstrate that this behavior in all BitTorrent clients, not a simple Transmission bug.

HOW TO READ THESE SCREENSHOTS

Each screenshot shows a different BitTorrent client downloading the same Ubuntu ISO torrent with speed capped at 15 KB/s both ways, next to a gnome-system-monitor showing overall network use. As a visual aid I've added a horizontal green line showing the "ideal" of where a constant 15 KB/s would lie on each g-s-m network graph.

> How are other clients able to control this global transfer[including over-head] too?
Vuze does this very well, if we set a global limit then it *is* honored.

No. As the screenshots show, Vuze has the same behavior. In fact, if you look at the magnitude and frequency of its deviations from the 15 KB/s goal, you'll see that it actually does much worse than Transmission.

[Vish (vish)]

@charles, thanks for taking time to test different torrent clients, much appreciated. :)

I dont believe i said the global limit is never crossed there are often spikes in vuze , but if i set a limit the limit is honored and i can browse pretty much quicker.

But transmission's handling of the global limit is pretty poor and this poor handling is not even known to the user unless they check elsewhere. the speed limit shown is misleading.

While we are comparing , here is how vuze behaves.

[Vish (vish)]

Similar comparison of transmission and how is fares at the same time

[Vish (vish)]

I give up trying to convince, just attaching the screenshots i took. The vuze version is the latest from their site , but i have traditional had no problems with vuze regarding speed throttling. If i set the speed even to 5kbs the speed is controlled pretty much closer , and sometimes i can even choke the speed to 1kb! but i could never make transmission get close to 5 even..

IMO , speed switch needs to be helpful, if i want to switch gears and start browsing , the torrent client needs to be able to slow down quick and effectively, but transmission does not handle this well at all ..! It is uses too much of a bandwith more than it is allotted . [other clients i used never had such problems, vuze on linux and windows/µTorrent on windows, etc..]

If there is some debugging i can provide do let me know, its just that i lost hope trying to convince with screenshots.. ;-)

But there *is* a problem in transmission.. absence of evidence does not effectively say that transmission is not faulty ...

[Lonnie Lee Best (launchpad-startport)]

Vish is right, Vuze honors limits quicker. Vuze may spike over, but then it levels off quickly (under or at the limit you've set) and gives the user the impression that his preferences are being enforced rather strictly.

When I monitor Transmission's adherence to my limits, it just angers me. For right now, I only use Transmission for small torrents, but anything big I still use vuze because of its strict adherence to my rate limits and its accurate and detail status monitoring.

[Charles Kerr (charlesk)]

@Vish, thank you for doing such an in-depth comparison of Vuze 4.5.0.4 and Transmission 1.93. Some of the editorializing was unhelpful, but other than that those were the most helpful datapoints I've seen to explain the behavior you're seeing.

However, I'm still not seeing the behavior you reported. I think it's likely that the difference is that I'm using Transmission 2.04+ and you're using 1.93.

In the spirit of your timed snapshots of Vuze 4.5.0.4 and Transmission 1.93, I've attempted to do a similar test for Transmission 2.04+. Snapshots to follow.

[Charles Kerr (charlesk)]

> When I monitor Transmission's adherence to my limits, it just angers me.

@Lonnie: It's a shame that you haven't harnessed that anger, because it doesn't make make the bug ticket any more productive. Maybe you could build a nightly tarball from https://build.transmissionbt.com/job/trunk-linux/ and give it a bandwidth test like the ones above that Vish and I made?

[Charles Kerr (charlesk)]

@Vish: in #transmission, Longinus00 noticed an important difference in the 1.9x and 2.0x tests that helps to explain their differences in behavior: 1.93 is much worse at managing the number of peers that we download from.

1.93
10:32: no speed limit; downloading from 38 of 56 connected peers
10:34: speed limited at 15/15; downloading from 52 of 60 connected peers
10:35: speed limited at 15/15; downloading from 44 of 56 connected peers
10:39: speed limited at 15/15; downloading from 58 of 60 connected peers
10:41: speed limited at 15/15; downloading from 60 of 60 connected peers
10:45: speed limited at 15/15; downloading form 59 of 60 connected peers

2.04+
00:48: no speed limit; downloading from 26 of 60 connected peers
01:36: speed limited at 15/15; downloading from 37 of 60 connected peers
04:xx: speed limited at 15/15; downloading from 13 of 60 connected peers
05:xx: speed limited at 15/15; downloading from 11 of 60 connected peers
07:xx: speed limited at 15/15; downloading from 9 of 59 connected peers

I'm tempted to reopen this and tie it to the upstream "Downloading from too many peers" ticket

[Vish (vish)]

@ Charles , i think Longinus00 is on to something here!
Downloaded Transmission 2.04 (11151) and i notice the same pattern too. the "downloading from" affects the downloading speed.

From testing behavior in Transmission 2.04 (11151) compared to earlier Transmission-1.93 (10621) :
[A] transmission is able to bring down the speed much quicker!
With 1.93 it took 10 mins minimum , but with 2.04 it takes around 2mins to bring down the speed.

But i notice that the number of peers "downloading from" changes randomly and the speed spikes at those times!
When there is an increase , the speed is not being controlled well.
Notice the speed at 18mins, that past min was high# of peers from, so the speed used was obviously higher during that min.

[B] But the speed indicated by transmission in the status bar is always misleading , it quickly changes the speed to what we have set and it seems to not know the actual speed it uses.

I think this bug needs to be considered in two parts:
1 : that transmission is not able to pause/control effectively the number of peers it downloads from
2 : wrong stats reported in the status bar.

Oddly, even if i start transmission with the temporary speed limits it downloads at full speed and then takes the same 2mins to stabilize.. [This is the same behavior with 1.93 , only that it takes 10+mins ;-)]
It seems that transmission just starts to download from everyone and then later realizes/calculates the speed it is supposed to be restricted at. There is a problem with such behavior if transmission is in the startup items : Bug #526898 , see comment #5 .

Can we re-open now.. ? :-)

Btw, isnt bug 563460 is a dup of this one.. ?

[Charles Kerr (charlesk)]

@Vish: could you please build a copy of Transmission from the tarball @ https://build.transmissionbt.com/job/trunk-linux/ and try that out and compare & contrast to the behavior you're seeing in 2.04 wrt the changing number of "downloading from" and random speed spikes?

[Charles Kerr (charlesk)]

> I think this bug needs to be considered in two parts:
> 1 : that transmission is not able to pause/control effectively the number of peers it downloads from
> 2 : wrong stats reported in the status bar.

Let's not clutter this ticket up yet further with this new distinction. 1. is related to this ticket's description; 2 is not. That should probably go in its own ticket.

[Charles Kerr (charlesk)]

vish: did you get a chance to try out a nightly build?

[Vish (vish)]

With the latest nightly,Transmission 2.04+ (11265), transmission seems to have gotten faster at being able to control the speed.
It takes under 1min to bring down the speed.

But it seems to have become over aggressive at controlling the speed, the speed limit was set at 15 , but the speed was quite lower, and the peers were lesser too when speeds got very low.

[Also, speed at start is still high even when started with speed limits set. same behaviour as earlier ]

For the wrong status bar speed limit , reported Bug #649294 .

[Lonnie Lee Best (launchpad-startport)]

@charles - I apologize for my impatience and I appreciate your continued support of this issue. Rate limiting is probably much more difficult than it may seem at the layer in which you are coding; when the layer underneath your code wants to do everything full-blast, I guess the best you can do is queue every transfer up, and stall the queue so that everything averages out to the user set limits. That my conceptualization of it, and that's probably wrong or "easier said that done". Thank you.

[Jason Harman (apollyon-direct)]

Perhaps related to this issue is Bug #649294 referenced by Vish. I wanted to share my experience where having uncapped upload and download results in continually low readings for my upload speed (usually around 15KBPS on a 70KBPS line) whereas my System Monitor reports continuous ~60KBPS range upload (which is correlated by my slow browsing experience). I have monitored this over days and hours with more or less other activity and it all seems to point to Transmission as the culprit. I'm worried also that this will result in skewed upload stats.

[Jason Harman (apollyon-direct)]

Also, I'd like to add that part of the problem with the divergence in capped speed vs actual speed is that Transmission reports actual speed as capped speed. What I would prefer to see is that when speed is capped, Transmission still report the actual speed (spikes and all) - this would at least make it easier to gauge Transmission's success - but as it is, it simply states the capped # when all data to the contrary shows that is not the case. So that even if all torrent clients have a problem accurately capping they should not have a problem accurately reporting their attempt to cap...

[Vish (vish)]

In Transmission 2.04+ (11266), the speeds are brought down better, but the problem now is that the speeds are brought down too much!
The speed controlled is much lower than the set value and often drops way lower,
Since it helps better to browse quicker when i want, but kinda makes the speed limit a not so great option if someone wants to always use the speed limit.

But this way it is much better than earlier IMO.

[Charles Kerr (charlesk)]

You are asking for a level of fine-grained network wizardry that is beyond my ability to provide.

You have been a very helpful bug reporter on this and other tickets, but you have also been rude at times and when I see this kind of nitpicking after I've banged my head against this ticket several times already I wish you would switch back to Vuze -- which, like Deluge, KTorrent, and Monsoon, falls shorter of your exacting criteria than Transmission does, as I recorded in the posts above on 9/18.

Alternately if you have a patch that will control the transfer speeds to the extent you suggest, I would be happy to use it so that I can forward these kinds of bug reports your way in the future.

I am closing this ticket as "Invalid" because it now concerns so many different issues that it is meaningless.

Do not reopen this ticket unless you have an actual important issue and have a material contribution to it, such as a patch or an analysis of libtransmission's existing network code.

[Vish (vish)]

*sigh* , I was not asking for more fine tuning but giving an update on the nightly that it is better now *for me* .
And the update was because you had pinged me earlier a while back on irc if i had tested the nightly and cause i had not reported back that it was better...

[Bruno Morais (bmorais)]

Well, I still see this behaviour in 2.04 (running Maverick), and it is quite problematic. If you use some network monitoring tool like 'nethogs' or anything similar, you will see the limiting issue pretty clearly. For testing purposes, I'm currently limiting upload speed to 5 KB/s, and seeing it reach 25-40 KB/s. I'm sure no overhead could account for this, and DHT is disabled.

[Charles Kerr (charlesk)]

Bruno, the 2.04 that you're using is older than the 2.04+ that was being discussed back in November. You need a newer version of Transmission if you want to see the improvements in r11266 that Vish and I were discussing.

That said, even the new version is not perfect -- and KTorrent, Deluge, and Vuze are worse -- because there doesn't appear to be a good way of controlling this at the application level. QoS tools are better suited for situations where you need truly fine-grained control.

[wolfen69 (wolfen69)]

I have a torrent set for 200kb a second, and it continues to use my full bandwidth. I have been a transmission user for a long time, and this is a first. Using ubuntu 11.10 64bit.

[Märt Põder (boamaod)]

Just for the record. I have this problem on Ubuntu 12.04 and Tansmission 2.51 too. Trying to set limits to 5kB/s whatever way, globally or per torrent, it still gets as much bandwidth as it can, that is far above 100kB/s.

[Märt Põder (boamaod)]

2.60 from https://launchpad.net/~transmissionbt/+archive/ppa doesn't solve the issue.

[Märt Põder (boamaod)]

It's the web seeds that doesn't honor my bandwidth limits. Disgusting.

[AraiBob (rhhyatt)]

TransmissonBT is very greedy when it comes to internet / ethernet bandwidth. Most other internet 'efforts' fail. Any idea how to fix? When to fix?

[Jason Harman (apollyon-direct)]

Been having that issue for a long time. Stops all my internet connections and yet when I check the status bar sometimes it only reads a few KBPS (I imagine that torrent 'overhead' is the problem but that seems uncontrollable since I've set speed limits well below my bandwidth allowance).

[Ari (ari-lp)]

I don't get why this bug is marked as invalid. At this moment transmission neither honours the regular nor alternative speed limits. And it's not about fine-tuning, either. As you can see in the attached screencast the actual download rate is so far off from the configured setting that this has to be a bug. The depicted rates also correspond with the total rates reported by the System Monitor.

>Unless somebody can show definitively that transmission is not honoring its own speed limits then I think this should probably be marked invalid.

I hope this screencast will be proof enough to remove the 'invalid' flag

Additional information:

$ apt-cache policy transmission-gtk
transmission-gtk:
  Installed: 2.51-0ubuntu1.3
  Candidate: 2.51-0ubuntu1.3

$ lsb_release -a
LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch
Distributor ID: Ubuntu
Description: Ubuntu 12.04.2 LTS
Release: 12.04
Codename: precise

$ uname -a
Linux AcerUBN 3.2.0-38-generic #61-Ubuntu SMP Tue Feb 19 12:18:21 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

[Charles Kerr (charlesk)]

Aristotelis, the kiwix torrent you're downloading in that video has a pair of webseeds, so what you're experiencing is bug #1058838 which is valid and tracked both in launchpad and upstream in Transmission's trac.

[Ari (ari-lp)]

Thank you, Charles. I subscribed to the launchpad report and cross-posted my experience there.