starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

Can't automatically set upload speed #13900

New issue

Open

opened 2026-02-22 00:27:33 -05:00 by deekerman · 19 comments

deekerman commented

2026-02-22 00:27:33 -05:00

Owner

Originally created by @ballo on GitHub (Oct 11, 2022).

Suggestion

This is a feature that's over 10 years old, so I'm not sure why it isn't more prevalent (tempted to file it as a bug). I'm always on the road and have to manually set this daily, or use a different client.

Use case

Everyone would find this useful

Extra info/examples/attachments

No response

Originally created by @ballo on GitHub (Oct 11, 2022). ### Suggestion This is a feature that's over 10 years old, so I'm not sure why it isn't more prevalent (tempted to file it as a bug). I'm always on the road and have to manually set this daily, or use a different client. ### Use case Everyone would find this useful ### Extra info/examples/attachments _No response_

deekerman added the

Feature request

Invalid

labels

2026-02-22 00:27:33 -05:00

deekerman commented

2026-02-22 00:27:42 -05:00

Author

Owner

@glassez commented on GitHub (Oct 12, 2022):

This is a feature that's over 10 years old, so I'm not sure why it isn't more prevalent (tempted to file it as a bug). I'm always on the road and have to manually set this daily, or use a different client.

It is completely unclear what exactly the requested feature should do.

@glassez commented on GitHub (Oct 12, 2022): > This is a feature that's over 10 years old, so I'm not sure why it isn't more prevalent (tempted to file it as a bug). I'm always on the road and have to manually set this daily, or use a different client. It is completely unclear what exactly the requested feature should do.

deekerman commented

2026-02-22 00:27:42 -05:00

Author

Owner

@ballo commented on GitHub (Oct 13, 2022):

Set the upload cap automatically like uTorrent or Vuze

@ballo commented on GitHub (Oct 13, 2022): Set the upload cap automatically like uTorrent or Vuze

deekerman commented

2026-02-22 00:27:42 -05:00

Author

Owner

@glassez commented on GitHub (Oct 13, 2022):

Set the upload cap automatically like uTorrent or Vuze

Description, examples, screenshots?
Or do you expect everyones know how uTorrent/Vuze do it?

@glassez commented on GitHub (Oct 13, 2022): > Set the upload cap automatically like uTorrent or Vuze Description, examples, screenshots? Or do you expect everyones know how uTorrent/Vuze do it?

deekerman commented

2026-02-22 00:27:42 -05:00

Author

Owner

@ballo commented on GitHub (Oct 15, 2022):

Instead of setting the upload speed manually, it's automatically set to whatever limit doesn't negatively affect downloading. It's a really, really old feature that works great.

@ballo commented on GitHub (Oct 15, 2022): Instead of setting the upload speed manually, it's automatically set to whatever limit doesn't negatively affect downloading. It's a really, really old feature that works great.

deekerman commented

2026-02-22 00:27:42 -05:00

Author

Owner

@thalieht commented on GitHub (Oct 16, 2022):

Ok. Looks like you won't explain. Is it an automatic per torrent upload speed you want?? Because a global upload speed limit already exists.

@thalieht commented on GitHub (Oct 16, 2022): Ok. Looks like you won't explain. Is it an automatic per torrent upload speed you want?? Because a global upload speed limit already exists.

deekerman commented

2026-02-22 00:27:42 -05:00

Author

Owner

@ballo commented on GitHub (Nov 8, 2022):

All you have to do is use Vuze/BiglyBT or uTorrent and the answer is self-evident as they automatically set the upload speed LIVE. This means even if your connection conditions change the app automatically limits the amount of packets sent upstream so it doesn't clog the downstream.

This is a very, very old feature and works well.

@ballo commented on GitHub (Nov 8, 2022): All you have to do is use Vuze/BiglyBT or uTorrent and the answer is self-evident as they automatically set the upload speed LIVE. This means even if your connection conditions change the app automatically limits the amount of packets sent upstream so it doesn't clog the downstream. This is a very, very old feature and works well.

deekerman commented

2026-02-22 00:27:42 -05:00

Author

Owner

@glassez commented on GitHub (Dec 26, 2022):

if your connection conditions change the app automatically limits the amount of packets sent upstream so it doesn't clog the downstream.

@arvidn, what do you think?

@glassez commented on GitHub (Dec 26, 2022): >if your connection conditions change the app automatically limits the amount of packets sent upstream so it doesn't clog the downstream. @arvidn, what do you think?

deekerman commented

2026-02-22 00:27:42 -05:00

Author

Owner

@ballo commented on GitHub (Feb 8, 2023):

This is how uTorrent does it:
https://forum.utorrent.com/topic/279-automatic-bandwidth-restriction/

@ballo commented on GitHub (Feb 8, 2023): This is how uTorrent does it: https://forum.utorrent.com/topic/279-automatic-bandwidth-restriction/ VUZE looks similar: https://wiki.vuze.com/w/Auto_Speed_Beta#Algorithm_details

deekerman commented

2026-02-22 00:27:42 -05:00

Author

Owner

@glassez commented on GitHub (Feb 10, 2023):

This is how uTorrent does it: https://forum.utorrent.com/topic/279-automatic-bandwidth-restriction/

VUZE looks similar: https://wiki.vuze.com/w/Auto_Speed_Beta#Algorithm_details

@arvidn
So what do you think about it anyway? Are you interested in implementing an automatic upload limit in libtorrent?

@glassez commented on GitHub (Feb 10, 2023): > This is how uTorrent does it: https://forum.utorrent.com/topic/279-automatic-bandwidth-restriction/ > > VUZE looks similar: https://wiki.vuze.com/w/Auto_Speed_Beta#Algorithm_details @arvidn So what do you think about it anyway? Are you interested in implementing an automatic upload limit in libtorrent?

deekerman commented

2026-02-22 00:27:42 -05:00

Author

Owner

@arvidn commented on GitHub (Feb 12, 2023):

Tha foundation of this feature is uTP, which ensures its upload speed is continuously adjusted to not interfere with real-time traffic (to the best of its ability). If anyone is unfamiliar with uTP, it's documented here and in more detail here.

As far as I know, the major remaining challenge is how to handle swarms where some peers use TCP and some use uTP. The TCP connections will inherently cause the uTP connections to throttle, causing an imbalance in allotted upload capacity between the two kinds.

I didn't quite follow the uTorrent thread, it looked more like a feature request than an explanation of what uTorrent implements. Fortunately, it was also sufficiently old that it predated uTP. The way uTorrent handles this situation is that it throttles TCP upload rates for all TCP connections (as a group) based on the upload rate experienced by all uTP connections (as a group). It takes int account how many connections each group has to approximately ascribe similar upload bandwidth to each peer connection. However, as we all know, not all peers have the same capacity, so this balance is regularly adjusted with a kind of low-pass filter. Let's say it's about every 10 seconds, if throttling the TCP connections did not cause the uTP connections to increase their upload rate, the TCP group is given more bandwidth, and vice versa. If it did cause the uTP group to increase its upload rate, then the balancing is moved one step closer to balancing out the capacity.

As you can tell, this makes movements slow (it kind of has to be, to let give the transports enough time to adjust). It also means that if there are sudden large changes in the mixture and capacities of peers, it may take a while to adjust the TCP/uTP balance. I was never really happy about this algorithm, but it was at least conservative in ensuring the upload capacity was well utilized.

In libtorrent, I went for a much simpler (and most likely worse) solution, implemented here. Every second the rate limits of TCP peers are adjusted to exactly be proportional to the actual rates achieved by uTP peers. i.e. this assumes that all peers have equal capacity, and the only limiting factor is the uTP throttling. i.e. there's no low-pass filter in adjusting the rates.
The behavior is controlled by the mixed_mode_algorithm setting.

@arvidn commented on GitHub (Feb 12, 2023): Tha foundation of this feature is uTP, which ensures its upload speed is continuously adjusted to not interfere with real-time traffic (to the best of its ability). If anyone is unfamiliar with uTP, it's documented [here](http://libtorrent.org/utp.html) and in more detail [here](http://bittorrent.org/beps/bep_0029.html). As far as I know, the major remaining challenge is how to handle swarms where some peers use TCP and some use uTP. The TCP connections will inherently cause the uTP connections to throttle, causing an imbalance in allotted upload capacity between the two kinds. I didn't quite follow the uTorrent thread, it looked more like a feature request than an explanation of what uTorrent implements. Fortunately, it was also sufficiently old that it predated uTP. The way uTorrent handles this situation is that it throttles TCP upload rates for all TCP connections (as a group) based on the upload rate experienced by all uTP connections (as a group). It takes int account how many connections each group has to approximately ascribe similar upload bandwidth to each peer connection. However, as we all know, not all peers have the same capacity, so this balance is regularly adjusted with a kind of low-pass filter. Let's say it's about every 10 seconds, if throttling the TCP connections did not cause the uTP connections to increase their upload rate, the TCP group is given more bandwidth, and vice versa. If it did cause the uTP group to increase its upload rate, then the balancing is moved one step closer to balancing out the capacity. As you can tell, this makes movements slow (it kind of has to be, to let give the transports enough time to adjust). It also means that if there are sudden large changes in the mixture and capacities of peers, it may take a while to adjust the TCP/uTP balance. I was never really happy about this algorithm, but it was at least conservative in ensuring the upload capacity was well utilized. In libtorrent, I went for a much simpler (and most likely worse) solution, implemented [here](https://github.com/arvidn/libtorrent/blob/765b304f324eeac5eca0a063442cf0974d0ce80b/src/session_impl.cpp#L3473). Every second the rate limits of TCP peers are adjusted to exactly be proportional to the actual rates achieved by uTP peers. i.e. this assumes that all peers have equal capacity, and the only limiting factor is the uTP throttling. i.e. there's no low-pass filter in adjusting the rates. The behavior is controlled by the `mixed_mode_algorithm` setting.

deekerman commented

2026-02-22 00:27:43 -05:00

Author

Owner

@ballo commented on GitHub (Feb 21, 2023):

Forgive my ignorance but why do you have to adjust individual peers instead of just throttling the overall upload bandwith use?

@ballo commented on GitHub (Feb 21, 2023): Forgive my ignorance but why do you have to adjust individual peers instead of just throttling the overall upload bandwith use?

deekerman commented

2026-02-22 00:27:43 -05:00

Author

Owner

@arvidn commented on GitHub (Feb 21, 2023):

@ballo
In my mind, "throttling the overall upload bandwidth" means: throttle individual peers such that the aggregate upload rate is at-or-below some specified limit.

I don't see how you can limit the aggregate without it boiling down to limiting individual peers.

@arvidn commented on GitHub (Feb 21, 2023): @ballo In my mind, "throttling the overall upload bandwidth" means: throttle individual peers such that the aggregate upload rate is at-or-below some specified limit. I don't see how you can limit the aggregate without it boiling down to limiting individual peers.

deekerman commented

2026-02-22 00:27:43 -05:00

Author

Owner

@ballo commented on GitHub (Feb 22, 2023):

Well, you could break that down to individual tcp pipes, too. Whether you aggregate them into 'peers' (each of which can have multiple pipes) or the connection as a whole is up to you.

@ballo commented on GitHub (Feb 22, 2023): Well, you could break that down to individual tcp pipes, too. Whether you aggregate them into 'peers' (each of which can have multiple pipes) or the connection as a whole is up to you.

deekerman commented

2026-02-22 00:27:43 -05:00

Author

Owner

@arvidn commented on GitHub (Feb 22, 2023):

one peer has one connection which is one TCP pipe (or a uTP pipe)

@arvidn commented on GitHub (Feb 22, 2023): one peer has one connection which is one TCP pipe (or a uTP pipe)

deekerman commented

2026-02-22 00:27:43 -05:00

Author

Owner

@ballo commented on GitHub (Feb 24, 2023):

@ballo commented on GitHub (Feb 24, 2023): OK

deekerman commented

2026-02-22 00:27:43 -05:00

Author

Owner

@luzpaz commented on GitHub (May 14, 2023):

@ballo can you refine both the title and the OP so that it reflects succinctly what is being requested. Then the 'invalid' tab can be removed from this ticket.

@luzpaz commented on GitHub (May 14, 2023): @ballo can you refine both the title and the OP so that it reflects succinctly what is being requested. Then the 'invalid' tab can be removed from this ticket.

deekerman commented

2026-02-22 00:27:43 -05:00

Author

Owner

@ballo commented on GitHub (May 19, 2023):

@ballo can you refine both the title and the OP so that it reflects succinctly what is being requested. Then the 'invalid' tab can be removed from this ticket.

I don't understand what you're requesting. The title reflects the ultra old feature other bittorrent clients have. You can always create another ticket and claim this one is a duplicate.

@ballo commented on GitHub (May 19, 2023): > @ballo can you refine both the title and the OP so that it reflects succinctly what is being requested. Then the 'invalid' tab can be removed from this ticket. I don't understand what you're requesting. The title reflects the ultra old feature other bittorrent clients have. You can always create another ticket and claim this one is a duplicate.

deekerman commented

2026-02-22 00:27:43 -05:00

Author

Owner

@xavier2k6 commented on GitHub (May 24, 2025):

ANNOUNCEMENT!

For anybody coming across this "Feature Request" & would like/love to see a potential implementation in the future!
Here are some options available to you:

Please select/click the 👍 &/or ❤ reactions in the original/opening post of this ticket.
Please feel free (If you have the "skillset") to create a "Pull Request" implementing what's being requested in this ticket.
(new/existing contributors/developers are always welcome)

DO:

Provide constructive feedback.
Display how other projects implemented same/similar etc.

DO NOT:

Add a "Bump", "me too", "2nd/3rd" etc. or "criticizing" comment(s).
(These will be disregarded/hidden as "spam/abuse/off-topic" etc. as they don't provide anything constructive.)

@xavier2k6 commented on GitHub (May 24, 2025): ## ANNOUNCEMENT! For anybody coming across this **_"Feature Request"_** & would like/love to see a potential implementation in the future! **Here are some options available to you:** 1. Please select/click the 👍 **&/or** ❤ `reactions` in the original/opening post of this ticket. 2. Please feel free _(If you have the "skillset")_ to create a **_"Pull Request"_** implementing what's being requested in this ticket. **_(new/existing contributors/developers are always welcome)_** ____ **DO:** * Provide constructive feedback. * Display how other projects implemented same/similar etc. **DO NOT:** * Add a "Bump", "me too", "2nd/3rd" etc. or "criticizing" comment(s). **(These will be disregarded/hidden as "spam/abuse/off-topic" etc. as they don't provide anything constructive.)**

deekerman commented

2026-02-22 00:27:43 -05:00

Author

Owner

@ballo commented on GitHub (May 29, 2025):

@ballo can you refine both the title and the OP so that it reflects succinctly what is being requested. Then the 'invalid' tab can be removed from this ticket.

I don't understand what you're requesting. The title reflects the ultra old feature other bittorrent clients have. You can always create another ticket and claim this one is a duplicate.

I don't know what's so hard to understand. There is a very useful feature that other clients have that qbittorrent lacks. Perhaps if you tried other BitTorrent clients you wouldn't be so confused.

To repeat myself (as there is no clearer way to state this), some BitTorrent clients you do not have to manually set the upload rate cap. It is done automatically, and this is a very very very nice feature which I don't ever want to do without especially since I have to switch ISPs often. It's a killer feature.

@ballo commented on GitHub (May 29, 2025): > > [@ballo](https://github.com/ballo) can you refine both the title and the OP so that it reflects succinctly what is being requested. Then the 'invalid' tab can be removed from this ticket. > > I don't understand what you're requesting. The title reflects the ultra old feature other bittorrent clients have. You can always create another ticket and claim this one is a duplicate. I don't know what's so hard to understand. There is a very useful feature that other clients have that qbittorrent lacks. Perhaps if you tried other BitTorrent clients you wouldn't be so confused. To repeat myself (as there is no clearer way to state this), some BitTorrent clients you do not have to manually set the upload rate cap. It is done automatically, and this is a very very very nice feature which I don't ever want to do without especially since I have to switch ISPs often. It's a killer feature.