Download speed suffering from uTP bandwidth management

[borring]

The rationale behind uTP is to be able to saturate the bandwidth without sacrificing regular internet usage. It automatically throttles when needed.

My problem is that uTP saturates my upload so much that my download suffers. I'm downloading a large torrent with a small swarm (6 seeds, 15 peers). The idea is that we no longer have to manage bandwidth caps ourselves

When I have:
* cap upload 100
* (x) enable bandwidth management (uTP)
* ( ) Apply rate limit to uTP connections
* (x) Apply rate limit to transport overhead

My speeds are something like:
60KB/s Down; 640KB/s UP

* cap upload 100
* (x) enable bandwidth management (uTP)
* (x) Apply rate limit to uTP connections
* (x) Apply rate limit to transport overhead

My speeds are something like:
650KB/s Down; 76KB/s UP

Why does uTP prioritize upload over download? I want to be able to contribute to the swarm, but I don't want the download to suffer because of it. Can uTP be taken advantage of in this way?

[ciaobaby]

https://github.com/qbittorrent/qBittorr ... ed'-issues

Measured rates please rather than "something like"

[borring]

According to speedtest:
27.32Mbps Down
5.66Mbps Up

I know how to saturate my download bandwidth. I'm just saying that in certain situations, uTP bandwidth management will prioritize upload speed over download speed. IIRC uTP tries to saturate upload speed without sacrificing latency. It automatically throttles itself based on some algorithm. I'm just pointing out that it has no regard for download speed. It'll saturate the uplink to the point that Download suffers.

[ciaobaby]

I know how to saturate my download bandwidth.

But the idea of setting up a BitTorrent client is to NOT saturate the Internet connection, if you have the limits set to leave no 'headroom'  for UTP to work with, it (UTP) is not going to be of any benefit, because it cannot work effectively.

It's not a 'magic bullet' that will just manage bandwidth regardless of how you set things up.

[Switeck]

"(x) Apply rate limit to transport overhead"

I usually have that disabled and try to minimize transport overheads by using conservative settings.

In theory, it's possible for transport overhead to be a large portion of the total traffic...especially if you allow 100's of connections at once. Each peer may be requesting pieces from your peer/seed. Each peer and seed communicate what pieces it has, so when a peer completes a new piece it uploads "hey I HAVE this piece now" to all connected peers and seeds. Peer Exchange (PEX) has peers+seeds tell each other the ips+ports of other working peers+seeds. Tracker updates may not happen very often per torrent, but if you have lots of torrents going at once with lots of trackers each and have always announce to all trackers enabled...that too has a bandwidth cost.

TCP/IP networking, which applies to a shocking degree even to uTP peers (UDP-using connections), means if you're downloading at 1 MB/sec the networking overheads on the upload side to keep that going is at least 2% of that (20 KB/sec) and may be as high as 25% of that (250 KB/sec) in extreme cases.