Qbittorrent: the upload limit affect the download speed

[yemlodis]

3.3.11 the officially package in arch linux
Qt: 5.8.0
libtorrent : 1.1.1.0
boost: 1.63.0

When i set the upload limit the download speed become slow and when i don't set a limit for the upload speed it back to the normal speed

This person has the same problem at Reddit :
https://www.reddit.com/r/torrents/comments/2yd32j/qbittorrent_download_speeds_so_much_slower_than/cqges4m/

[Misiek304]

Isn't this like normal?
Every TCP connection must be acknowledge by sending a message that you've reserved it. So when you limit your upload you're also limit the ability the number of connection you're able to acknowledge.

This is very simplified. In practise it's way more complicated.

[Chocobo1]

@yemlodis
Make sure "Apply rate limit to transport overhead" is unchecked (in Options -> Speed tab).

[Seeker2]

If you put the upload limit too low, other peers and seeds many auto-snub or manually ban your ip and your download speed can suffer immensely as a result.
Snubbing is built into the BitTorrent protocol, but it's only supposed to kick in if an attempt to upload a single 16 KB chunk takes longer than ~30 seconds to that peer. This can happen if you allow too many upload slots at once relative to max upload speed and/or your BT client is counting overheads against the upload limit and you're downloading quickly.

[Misiek304]

@Seeker2 - Question: How do I check if I'm a snub? Is there like a formula I can use to calculate max number of slots for my upload speeds?

[Seeker2]

I've seen uTorrent snub other peers and even seeds -- they get the S flag in the peers window. qBitTorrent may show the same as well.
You can't tell if OTHER peers snub you -- you just get nothing from them even if you were getting a lot before. Not to be mistaken for when a peer lacks pieces your end wants now, like when downloading pieces or files sequentially.
Getting a piece hash fail may earn a snub before being auto-banned for additional hash fails.
Other peers may also "mutiny" by disconnecting after getting nothing for longer than their inactive delay timer -- and snub your ip if it reconnects.

The absolute minimum allowed by the protocol:
Divide your total upload speed to peers by global upload slots...that gets rough average KB/sec upload speed to a single upload slot/peer.
Uploading 16 KB to a single peer in 30 seconds is barely faster than 0.5 KB/sec (because 15 is half 30), so your average KB/sec UL per upload slot needs to be >0.6 KB/sec.

Barely avoiding being snubbed isn't a good idea... BitTorrent starts falling apart if upload speeds are too low because a piece cannot be shared until it's fully downloaded AND passes hash check.
With 1 MB (1024 KB) piece size, a seed/peer could upload to 100 peers at once at 1 KB/sec each (for 100 KB/sec upload speed total) for 16 minutes straight and none of them has a completed piece yet to share with each other:
Seen on "Feast-Or-Famine" torrents which have only 1 seed -- your download will be 0 most of the time, then you'll get firehosed a single piece from the other peers, and back to 0 DL again!
...made worse if the lone seed uploads 1st/last pieces repeatedly because new peers demand those pieces first.

Most BT clients upload to the peers uploading the fastest to them (Tit-For-Tat a core part of BitTorrent). They have 1 "optimistic unchoke" (O flag) upload slot which uploads to random peers instead.
Upload isn't split equally between upload slots either -- the fastest peer can get >50% of the total so long as the slowest upload slot can get >5 KB/sec.
Many peers upload back far more than they get from you because they're fast and/or poorly configured.
(It's a bit like 2 hikers in the woods...you don't need to outrun a bear, just the other hiker!)

Decent downloading settings are often terrible if only seeding...so busy public torrents often have lots of do-nothing "seeds" because they're uploading to 0-4 peers but connected to 40+.
Here's a request to reduce do-nothing seeding behavior: https://github.com/qbittorrent/qBittorrent/issues/2193 Milestone: qBitTorrent v3.2.1

[gotwig]

I am not going to use qBittorent any more, because Transmission does NOT have this issue.

The developers of qBittorent built this into the torrent client to FORCE users to upload, even though its OPTIONAL and users should have the FREEDOM to chose how they PLEASE.

[FranciscoPombal]

If you set the upload limit too low you will not get as many pieces back. This is by design of the BitTorrent protocol itself. If you think another mainstream client like Transmission behaves differently, there is something wrong with your tests. For example, you might not have "Apply rate limit to transport overhead" unchecked, and are thus not comparing apples-to-apples.