Download speed limited

[Angel-60]

Please provide the following information

qBittorrent version and Operating System

v4.2.5 Windows 10 Pro 64bit

If on linux, libtorrent-rasterbar and Qt version

(type here)

What is the problem

My download speed wont go over 12 MiB/s (Max 12.2 MiB/s)

What is the expected behavior

To unlimit my download speed

Steps to reproduce

Just install an torrent

Extra info(if any)

Some photos with my qBittorent settings:

Click to show

       

My speeds:

Click to show


[FranciscoPombal]

@arugolanu

Please upload images directly as attachments to your post, do not use external image hosts.

Your maximum speed will depend on multiple factors: Bandwidth of the swarm, network speed, CPU speed, disk speed, some qBittorrent settings, network usage by other programs, ... If the torrent is simply not seeded enough and/or your computer can't keep up and/or qBittorrent is incorrectly configured, you'll never hit your maximum theoretical speed speed. For example, even in a well-seeded torrent and with a fast CPU, it will be very hard to hit your theoretical maximum of around 90~100 MiB/s on most HDDs, especially with more than one torrent running.

To rule out an issue on your end, please first test with the following:

• No other torrents added (or at least, all other torrents paused)
• As little as possible background stuff running
• Async I/O threads in the advanced settings set to 4 times the number of your CPU cores.
• The latest Ubuntu torrent, which has a fast enough swarm that will not be the bottleneck (link: https://releases.ubuntu.com/20.04/ubuntu-20.04.1-desktop-amd64.iso.torrent)

Also, please provide more details about your specs, such as CPU model, HDD/SSD, RAM, ...

[Angel-60]

I attach the images up. That Async I/O threads setting kinda helped, my speed went from 12 to 24 which is way better. My configuration: Ryzen 5 3600,WD Blue 1TB SATA-III 7200 RPM, HyperX predator 8GB 3200,rtx 2060

[FranciscoPombal]

@arugolanu

I edited your posts to put the images in the OP behind clickable tags.

Experiments have shown that SSDs benefit from basically as many hashing threads as you can throw at them. At the same time, there's also no benefit to having more hashing threads than the number of CPU cores (or sometimes Hyperthreading/SMT threads, which in current processors just means further multiplying by 2). Currently, libtorrent spawns 1 hashing thread in every 4 async I/O threads; hence the advice to set async I/O threads to 4 times your CPU cores (4*6 = 24), which in your case would result in 24/4 = 6 hashing threads - one per CPU core.

On the other hand, HDDs start to choke at 3 or more hashing threads, no matter how fast the CPU is, due to their poor random read/write performance. So, since you have an HDD, you are actually better off setting async I/O threads to 8, which will result in qBittorrent using 2 hashing threads from libtorrent. Furthermore, and HDD will disproportionately benefit from setting "sequential download" ON (for SSDs it basically doesn't matter), and downloading only one torrent at a time (again, this would not be a bottleneck for SSDs).

Here's the link to the results: https://github.com/arvidn/libtorrent/wiki/disk-I-O-settings-for-checking-files

So in your case, I would recommend setting async I/O threads to 8. I you download the ubuntu torrent with "sequential download" turned on with no other torrents active, you should be able to get pretty close to your theoretical max network speed, assuming no other bottlenecks caused by other programs (anti-virus software is typically a prime suspect, so you can try a run with it disabled to see the difference), because your disk should at least be capable of that (certainly more than 24 MiB/s).

As a side note, your system will feel much snappier overall if you upgrade to a SATA or NVMe SSD. If you don't have one already, it's the biggest individual upgrade you can make to basically any PC.

[Seeker2]

Alternate DL/UL speed limits are roughly 10x faster than the linespeeds shown in the speed test. (Telling a car to go 1000 MPH when it can only go 100 MPH doesn't work well either.)

On torrents that don't have 10x as many seeds as peers -- you need more upload slots in order to achieve both a higher upload and download speed. Allowing 20 total spread across every torrent means... past those 20 peers you're uploading to, all the rest are getting nothing from you at that given moment. (You gave them nothing, they'll give you nothing back.) The upload slot peer choice only changes about every 15 seconds to 5 minutes, and then typically only a couple change not all...many will never get anything from you with only 20 max upload slots.

[Angel-60]

With async i/o on 8 i managed to get 33-38 MiB/s on a torrent with 90 seeders. I got an ssd but i usually install torrents on the hdd. I installed that ubuntu torrent, burn it but now i don't really know how it works.

[Seeker2]

The Ubuntu torrent is only meant to be used as a speed test torrent, the contents of the torrent is almost inconsequential in terms of the test...and is best left to people who actually want to use Ubuntu. (a Linux-based Operating System)

[FranciscoPombal]

@arugolanu

With async i/o on 8 i managed to get 33-38 MiB/s on a torrent with 90 seeders.

It's pointless to do speed tests with random, unspecified torrents. For all you know, that might have been the maximum bandwidth the swarm of that particular torrent had to offer to you. On the other hand, the latest Ubuntu torrents are known to have basically "infinite" bandwidth available, because at any given time there are hundreds/thousands of seeds on high-bandwidth seedboxes and university servers available, so they will not be the bottleneck for sure.

Like Seeker2 said, the point of the Ubuntu torrent is to serve as a good test torrent for speed benchmarks. The content doesn't matter. Basic steps for a proper speed benchmark: You stop all other active torrents, close other background programs, load the Ubuntu torrent, set "sequential download" to ON, set async I/O to 8 since you have an HDD (this you already did) and you should observe the best-case scenario speed you will obtain with your HDD. You can also try enabling/disabling anti-virus as another test variable. Anti-viruses have a tendency to very negatively impact I/O performance.

By all means do try using Ubuntu as your OS in your spare time though :). I am more of a Xfce man myself, so if I were to go with an Ubuntu base, I would choose Xubuntu instead, though.

[Seeker2]

For smaller torrents, I download to a ramdrive (up to ~6 GB size, as I have 12 GB ram) and then have qBitTorrent move the completed torrent to a HDD. Vastly reduces file fragmentation that way too.

[levicki]

@FranciscoPombal

For that kind of connection speed he should probably increase connections per torrent and maximum connections values, and make sure that EnableConnectionRateLimiting value of type REG_DWORD in registry key Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters is set to 0. It should be created if it doesn't exist, and system must be rebooted for the change to take effect. That setting disables limiting of the number of active TCP half-open connections which should help with download startup and speed up the peer discovery.

[FranciscoPombal]

@levicki

Thanks, but:

@FranciscoPombal

For that kind of connection speed he should probably increase connections per torrent and maximum connections values,

I can reach Gigabit speeds with the Ubuntu torrent with just the default settings in qBittorrent except async I/O turned up to the appropriate value. Of course, it does not hurt to bump those limits up anyway (since it can lead to better results in other torrents), if the associated increase in resource consumption is acceptable.

and make sure that EnableConnectionRateLimiting value of type REG_DWORD in registry key Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters is set to 0. It should be created if it doesn't exist, and system must be rebooted for the change to take effect. That setting disables limiting of the number of active TCP half-open connections which should help with download startup and speed up the peer discovery.

That was important in the Windows XP days, but has not been relevant for a long time. Windows versions >= Vista SP2 don't have a half-open limit at all and basically just ignore this setting: https://www.mydigitallife.net/half-open-outbound-tcp-connections-limit-removed-in-windows-7-and-vista-sp2-no-patch-required/

[levicki]

Windows >= Vista SP2 don't have a half-open limit at all and basically just ignore this setting

Sorry, but the link you posted does not say that. Limit definitely exists (as in there is code in tcpip.sys checking that key), and thus the setting works, even if it now defaults to unlimited if no value is present.

Setting it to 0 just makes sure that if the default changes again you still have yours set to unlimited.

[FranciscoPombal]

Sorry, but the link you posted does not say that. Limit definitely exists (as in there is code in tcpip.sys checking that key), and thus the setting works, even if it now defaults to unlimited if no value is present. Setting it to 0 just makes sure that if the default changes again you still have yours set to unlimited.

For Vista SP2 sure, but for Windows 7 and later, which is the minimum version supported by qBittorrent ATM, it is not even implemented:

Windows 7: Half-open TCP connections limit is not implemented in Windows 7 since Windows 7 Beta release. So no patch is necessary.

But that's not even that important because...

Setting it to 0 just makes sure that if the default changes again you still have yours set to unlimited.

...it is extremely unlikely that the default will change again. The limit was in place previously because it was a half-assed band-aid attempt by Microsoft of solving other problems. Predictably, the limit ended up causing more problems than it solved, so it was removed.

[Seeker2]

For that kind of connection speed he should probably increase connections per torrent and maximum connections values

Global max connections might be worth increasing if running lots of torrents, but 100 connections per torrent should be sufficient even for symmetric gigabit/second fiber lines. If Tit-For-Tat does not work well enough with 100 connections, adding more may cause more problems instead of helping.

[levicki]

it is not even implemented...

So what is this then?

And before you say "That's not tcpip.sys!", yes I know -- Microsoft has split network drivers into modules, the module above deals with registry settings and initializing some sort of global context for tcpip.sys which has the following code in it:

So, maybe check with a reliable source next time before claiming something is not implemented.

[FranciscoPombal]

@levicki

MDL is most certain a reliable source for this kind of Windows-related stuff, but even reliable sources make mistakes, nothing I can do about that. It's also possible they re-implemented it later, since the original article makes claims for Windows 7/Windows 7 Beta, not later versions (I'm assuming you're on Windows 10).

Bu then again:

But that's not even that important because...

Setting it to 0 just makes sure that if the default changes again you still have yours set to unlimited.

...it is extremely unlikely that the default will change again. The limit was in place previously because it was a half-assed band-aid attempt by Microsoft of solving other problems. Predictably, the limit ended up causing more problems than it solved, so it was removed.

I believe it is best not to instruct users to mess with the registry if they don't have to. Windows users are typically less tech-savvy and experienced, telling them to change stuff in the registry is risky and bad just bad UX. "Unlimited" has been the default for 10+ years and it's not going to change, unless something very drastic and/or weird happens.

[levicki]

MDL is most certain a reliable source for this kind of Windows-related stuff, but even reliable sources make mistakes, nothing I can do about that

They never claimed it was completely removed from Windows like you did, just that the limit was removed as a default.

[FranciscoPombal]

@levicki

They never claimed it was completely removed from Windows like you did, just that the limit was removed as a default.

It was not my claim, this is a direct quote from their article:

Windows 7: Half-open TCP connections limit is not implemented in Windows 7 since Windows 7 Beta release. So no patch is necessary.

I think it was reasonable for me to interpret "not implemented since" as "it got removed". As you proved in https://github.com/qbittorrent/qBittorrent/issues/13278#issuecomment-680373253 though, looks like they were wrong anyway, or at least that statement no longer accurately reflects the situation.

---

Anyway, this is getting off-topic, and I believe the core issue has been solved - from what we know, the performance issues reported in the OP are not caused by some bug in qBittorrent. So this is the same scenario observed many times before: since an HDD is being used, correctly configuring and tuning (e.g. setting libtorrent's async I/O threads setting to 8) and downloading one torrent at a time sequentially minimizes the bottleneck caused by the HDD. But no amount of tuning is going to overcome that bottleneck in the end, especially when multiple torrents are active at a time or not downloading sequentially - qBittorrent/libtorrent already squeeze whatever performance they can out of it.