Fluctuating speeds with certain torrents (or it seems like that at the speedgraph).

[Nemo-qB]

qBittorrent version and Operating System
qBittorrent v4.2.2 / W10 64bit (latest).

What is the problem
The speedgraph shows fluctating speeds. Also I see that my speed go up and down (between around 9.0MiB/s and 5.0MiB/s and sometimes jumps to my max for few seconds) so it confirms the speed is going up and down for some reason. My max downloadspeed is around 12MiB/s at the moment.

What is the expected behavior
While this doesn't happen with every torrent with large torrent it seems to happen more often. Especially with big piece sized torrents from my experience. I want it to stay at stable speeds when there is more seeders than leechers available. For some reason it goes up and down which shouldn't be happening. Downloading to HDD and SSD doesn't solve it by the way. My system is doing nothing else on the background.

Steps to reproduce
Its random. But as I said it does happen with large torrents with big piece sizes in general. Thats what I have found for myself.

Extra info (if any)
Advanced settings is all default. I only changed my own settings within speed and connections tabs.

See the screenshot, enough seeders to max out but still seeing the speedgraph from last 5 minutes (if its working right) you can see the speeds go up and down. Not once but it keeps doing it till the download is finished. In this case it was 32GB in size as shown.

[FranciscoPombal]

Advanced settings is all default. I only changed my own settings within speed and connections tabs.

But is this a clean install or an upgrade? Do you have disk cache set to auto? If not, try setting it to auto, or a relatively high value like 400 MiB.
Also bump up the number of asynchronous IO threads to 4 times the number of hardware threads your CPU has (i.e. if your CPU has 4 cores and 8 threads set async IO threads to 4*8 = 32).

Also: did this start happening with 4.2.2?

[mcmuttons]

I'm having the same problem, with maybe even more extreme spikes. It's an upgrade, disk cache is set to auto. I tried bumping up the asynchronous IO threads, and it made the problem worse.

You can see in this speed graph exactly where I bumped up the IO threads, where the spaces get way longer between the spikes. Then I went all the way the other way and set the threads to 1, which brings the result on the far right, where the spikes are close again (maybe even closer than with 4).

[mcmuttons]

Just for reference, I tried downgrading to 4.2.1 to see what would happen, and this is what the speed graph looks like then. (I've got the download max set to 15000 kbps)

[FranciscoPombal]

@arvidn requesting advice please

[mcmuttons]

Just to tack on another data point which makes me think it has something to do with the auto allocation for the disk cache. In my 4.2.1 install, I noticed spikes after a while (not as bad as in 4.2.2), and based on one of the other bug reports here, decided to up the memory allocation for the cache from 64MB to 128MB. That smoothed things out in 4.2.1.

Then it occurred to me that in 4.2.2, the cache allocation had been set to auto, so I've gone back to 4.2.2 again. This time it kept the 128MB allocation (maybe because I'd set it manually rather than the default in 4.2.1?), and things were smooth.

So again, as a test, I set it to auto allocation and let it run for a while. Spikes came back. The below picture shows what happened when I went from auto back to a 128MB cache. Everything stopped for a little while, and then it bumped back up to a steady 15Mbps or so. This is in 4.2.2.

The spikes on the left are auto, the lull in the middle the transition period and to the right with the 128MB cache.

[Nemo-qB]

Thanks Francisco Pumbal.

Its a clean install. Disk cache is on auto (default setting). I thought about the disk cache setting too. Its like maxing out my speed and then drops for few seconds and when the cache is available again it speeds up. This vicious cycle causes the fluctating was my first thought.

Interesting find mcmuttons, I will try and set it at 128MB cache too when im at home.

I will post my results with the advices, thanks.

[FranciscoPombal]

@Nemo-qB @mcmuttons
Please post:

• The amount of RAM your machine has
• The minimum value you can manually set the cache to that does not result in the spikey behaviour (does not need to an exact value, can be a ballpark within a few dozen MiB or so. I recommend using a binary search procedure to make the process faster. For example, if 128 MiB is good, try with 64 MiB. If still good, halve again. If not, bump to 64+(128-64)/2 = 64 + 64/2 = 64+32 = 96 MiB. If good again, reduce to 96-(96-64)/2, if not, bump to 96+(96-64)/2 and so on. No need to go until the end, you'll reach a small interval of possible values in very short time.

With these 2 datapoints we can get closer exactly what the problem is with auto, because libtorrent uses the amount of total system memory to determine the value of auto.
The code is here: https://github.com/arvidn/libtorrent/blob/2d7875385e00f5e8ad66db1bc1dd5c44d222a5a9/src/disk_buffer_pool.cpp#L298

Because 5 GiB > 4 GiB and 5 GiB/40 = 128 MiB, and given that with 128 MiB, performance is good for @mcmuttons, we can deduce that if the spikes have to do with lack of cache, @mcmuttons machine has to have less than 5 GiB RAM. With these assumptions, it's the only scenario where auto would cause the spikes.

[mcmuttons]

I don't have time to do the narrowing down right now, though I can try it tomorrow. However, my machine has 16GB of RAM.

[FranciscoPombal]

@mcmuttons

However, my machine has 16GB of RAM.

Big oof. This thickens the plot a bit. When you have the rest of the results let us know.

[Nemo-qB]

Some interesting things have happened while playing with the cache settings.

Here are the test results, watch the speedgraphs too:

128MB Test 1:

Looks fine, at some point it stayed stable at my max current download speed. RAM usage around 180MB.

64MB Test:

It took some time to speed up and while with 128MB I maxed my speed with 64MB this wasn't the case. It maxed at around 8.0MiB/s. Didn't go much higher than that.

128MB Test 2:

Great results again. RAM usage around 172MB and as seen on the speedgraph the speed was quite stable at some point reaching my max.

By the way my system has 16GB DDR4 memory.

[FranciscoPombal]

@Nemo-qB Thanks, it sounds increasingly more likely that there could be some problem with auto.

[arvidn]

understanding these kinds of problems is exactly what the session stats / performance counters are for. In an ideal world, the qbt graph would be able to plot all metrics (not just the downloaded and uploaded bytes).

Anyway, I would be interested in knowing if this could be an issue in uTP. Could you try disabling uTP and also try disabling TCP, so see if that affects anything.

[Nemo-qB]

Here are the test results with different cache settings and uTP/TCP options.

128MB, uTP disabled, only TCP:

Quite stable, memory usage around 171MB.

128MB. TCP disabled, only uTP:

Even better than the first one in my opinion. Straight line speed without any huge spikes or fluctating behaviour. Memory usage around 182MB.

64MB, uTP disabled, only TCP:

Mixed feelings. Not quite stable and it took much longer to even max my speed. Memory usage around 122MB.

64MB. TCP disabled, only uTP:

Compared to the TCP test this one was actually very good. Maxed my speed within seconds and it stayed like that as shown at the speed graph. Memory usage around 118MB.

Auto cache, only uTP:

Auto cache, only TCP:

Using auto cache has bad influence in both situations. uTP seems to have more spikes and fluctating problems with it but TCP is also effected. This could explain the speed problems that some are experiencing. The memory usage of both tests is the lowest of all comparisons.

I personally don't really care that much about memory usage as long the performance is good. I got 16GB so its more than enough. Thats why I keep my cache setting at 128MB for now to see how it goes with different torrents. If im right uTorrent is set at 128MB too as default.

If there is someting else I can test let me know, thanks.

[Nemo-qB]

Random 5GB big torrent, 128MB cache and mixed connections TCP and uTP:

Perfectly fine.

[xavier2k6]

@FranciscoPombal @arvidn @sledgehammer999

Another point of note is that when auto disk cache is set, the "buffer size" in the statistics view usually remains at 0 or fluctuates between 16KiB 32KiB 48KiB 64KiB (See Pic above)

Yet if you set the cache to a set amount like 64MiB 128MiB 256MiB 512MiB 1024MiB etc it will correctly show these set/defined figures +few bytes...

So, is the libtorrent auto cache algorithm working correctly & if it is, why is qBittorrent not setting the end result to the desired amount derived from the algorithm's calculations?

Are the spikes from qBittorrent going back & forth trying to figure out the setting?

this is the logic to calculate the automatic disk cache size

[FranciscoPombal]

@arvidn I debugged the cache size selection code for a while, and the only way I could see this failing would be if total_physical_ram() somehow returned 0, which means cache will default to 16 MiB (1024 * 16 KiB block size), which is very little and would explain these symptons.

Now, I did not look closely at total_physical_ram() (it's not very pleasant to glance at such #ifdef hell either), but if it's not absolutely guaranteed that it always returns a value >= 0, you might want to change that.

Also, if it returns 0, you might want to change the default cache value to something higher than 16 MIB, say 32 or even 64 MiB. But this still won't be enough for many cases, and it's not a real solution to have the fallback value be very high, so you should probably issue an alert. Something like cache_size_alert?

[arvidn]

well, I just found a bit of an embarrassing bug. I was truncating the total physical RAM to a signed 32 bit int. So, 16 GiB would become 0.

How does this look? arvidn/libtorrent#4506

[FranciscoPombal]

How does this look? arvidn/libtorrent#4506

I don't have a machine with 16 GiB or more available to test right now unfortunately.

[xavier2k6]

will compile a build with arvidn/libtorrent#4506 & run on test system with 32GB Ram.

[FranciscoPombal]

@xavier2k6 make sure to test with and without it. Also, if possible, set a breakpoint at the relevant location in the libtorrent source and observe the value that is returned from the function with and without the patch.

[Nemo-qB]

Nice find, hopefully it will be fixed as I think that the most of the speed problems is caused by this behaviour. At the moment im using 128MB cache without issues for now (v4.2.3).

[FranciscoPombal]

@xavier2k6 have you managed to test this successfully?

[Nemo-qB]

I have slowly set my cache to higher values from 128/256/512 and I let it stay at 512MB for now. I hear that my system is much more quieter and performs excellent.

[FranciscoPombal]

I have slowly set my cache to higher values from 128/256/512 and I let it stay at 512MB for now. I hear that my system is much more quieter and performs excellent.

512 MiB is relatively close to what auto would have set for 16 GiB of RAM if it were working properly.

[Ryrynz]

@sledgehammer999 I think it would pay to not wait too long before releasing 1.2.4 as this would be affecting quite a few people.

[Disco-Chef]

I too also went from auto to 128MB for the cache and instantly, the random bottoming out. You can notice clearly when I hit "apply" on the setting

[FranciscoPombal]

@xavier2k6

will compile a build with arvidn/libtorrent#4506 & run on test system with 32GB Ram.

@xavier2k6 make sure to test with and without it. Also, if possible, set a breakpoint at the relevant location in the libtorrent source and observe the value that is returned from the function with and without the patch.

friendly ping, any results so far?

[xavier2k6]

@xavier2k6

will compile a build with arvidn/libtorrent#4506 & run on test system with 32GB Ram.

@xavier2k6 make sure to test with and without it. Also, if possible, set a breakpoint at the relevant location in the libtorrent source and observe the value that is returned from the function with and without the patch.

friendly ping, any results so far?

I created a build with that patch - haven't had time to fully test it in detail & post results etc but have noticed cache stats now go to ~867MiB

I'm going to attach the build here when it's uploaded to dropbox.

EDIT: File below:
qbittorrent 4.2.3 with libtorrent #4506

[FranciscoPombal]

@xavier2k6

I created a build with that patch - haven't had time to fully test it in detail & post results etc but have noticed cache stats now go to ~867MiB

800 MiB+ for disk cache is expected for a 32 GiB system with the current libtorrent code.

@Nemo-qB @Disco-Chef @mcmuttons can you please test this build? Set the disk cache to auto and see if the problem is fixed (i.e. if the speed is stable)

EDIT: File below:
qbittorrent 4.2.3 with libtorrent #4506

Also screenshots comparing Total buffer size in view->statistics between 4.2.3 and the patched build would be helpful.

[mcmuttons]

I'll install it tonight and see. Sorry about not getting back with results from back earlier, but things got really busy, and it seemed like you guys were already getting a good grip on the issue.

[FranciscoPombal]

@mcmuttons

I'll install it tonight and see. Sorry about not getting back with results from back earlier, but things got really busy, and it seemed like you guys were already getting a good grip on the issue.

Thanks, we're pretty certain this should be fixed at this point, but further confirmation from you and the others would be nice.

[FranciscoPombal]

@arvidn out of curiosity, I noticed that we use the disk.disk_blocks_in_use performance gauge as the data source for the value of total buffer size in the view->statistics window. Is this the correct gauge to view the current value set by cache_size?

[xavier2k6]

Official 4.2.3 set to AUTO (no patch)

4.2.3 set to AUTO with arvidn/4506

[FranciscoPombal]

@xavier2k6

A little strange for the first screenshot to just show 0, but what matters is the patched version seems to be working correctly.

[xavier2k6]

#12336 (comment)

It varied slightly but maybe it is different for people who have less than 16GiB, since I have 32GiB & the incorrect logic was found from 16GiB+

EDIT:

well, I just found a bit of an embarrassing bug. I was truncating the total physical RAM to a signed 32 bit int. So, 16 GiB would become 0.

I can only show what it is showing for me & I don't really have the time to be pulling hardware to test various RAM configs.

Hopefully the logic is correct now & in future I will be able to test with 64GiB / 128GiB + systems.

[Nemo-qB]

The tests:

Official 4.2.3 set to AUTO (no patch)

4.2.3 set to AUTO with arvidn/4506

As you had mentioned before @FranciscoPombal;

512 MiB is relatively close to what auto would have set for 16 GiB of RAM if it were working properly.

It comes close to it and I can confirm that this patch works perfectly as it should.

I think a new release only for this fix is already critical and most of the speed issues here at Github and at the forum will be over, hopefully.

EDIT:

Maybe a dumb question but I was just wondering; Is it normal that the read cache stays at 100% for like 45sec/1min? Then it dropped slowly to around 15% and lower. The torrent was around 32GB in size, same from the tests before. Speed was fine.

[FranciscoPombal]

Maybe a dumb question but I was just wondering; Is it normal that the read cache stays at 100% for like 45sec/1min? Then it dropped slowly to around 15% and lower. The torrent was around 32GB in size, same from the tests before. Speed was fine.

I think it makes sense, at the start everything can be read from the cache, and as it gets overrun, the hit rate goes down.

[arvidn]

out of curiosity, I noticed that we use the disk.disk_blocks_in_use performance gauge as the data source for the value of total buffer size in the view->statistics window. Is this the correct gauge to view the current value set by cache_size?

I think that's reasonable. It will include buffers that have just been received from peers and may be queued up to be inserted into the cache as well. It will also include buffers that have been read from disk and are currently waiting in the send-queue to a peer that requested it.

in other words, even when the cache size i 0, that gauge is likely not always 0.

[FranciscoPombal]

@arvidn

I think that's reasonable. It will include buffers that have just been received from peers and may be queued up to be inserted into the cache as well. It will also include buffers that have been read from disk and are currently waiting in the send-queue to a peer that requested it.

in other words, even when the cache size i 0, that gauge is likely not always 0.

Hmm, then it is not quite what I had in mind - I was actually expecting it to include only the memory related to cache_size, and nothing else. What would be the metric for that? It would be the sum of disk.write_cache_blocksand disk.read_cache_blocks, right?

[arvidn]

yes, that's correct. write_cache_blocks will not include blocks that are queued to be inserted into the cache. However, read_cache_blocks does include blocks that are pinned in the cache because they are being sent to a peer. If you want to exclude those, you can subtract pinned_blocks. But I don't think that makes sense, a pinned block is still in the cache, and can be sent to multiple peers simultaneously. Being pinned just means it can't be evicted, since it's in use.

[Nemo-qB]

I have redirected at the forum some of the users to the fixed exe as a temporarly solution: https://qbforums.shiki.hu/viewtopic.php?p=33611#p33611

Can we expect a release soon for everyone (@sledgehammer999) or are we going to wait till libtorrent 1.2.6 is being released first including the fix?

[xavier2k6]

@Nemo-qB There is another issue #11735 for Proxies/UDP that needs to be ironed out as well & devs from qBittorrent/libtorrent can hopefully have that resolved in the next few days, so a release should be after that as these are both big user base issues.

[Nemo-qB]

https://qbforums.shiki.hu/viewtopic.php?f=14&t=8158
https://qbforums.shiki.hu/viewtopic.php?p=33630#p33630

Another confirmation which is nice. We can agree and say that the fix works as it should.

[xavier2k6]

Another confirmation which is nice. We can agree and say that the fix works as it should.

Great, we can concentrate our efforts now on #11735 & help get a new "release" out soon after.

[Chocobo1]

Closing...

Just for the record, it started since this: #11637
A bug in libtorrent was discovered and fixed: arvidn/libtorrent#4506
qbt also employ a proper workaround now: #12416

For anyone facing the issue, go to Options -> Advanced -> Disk cache and change from auto to 64 MiB or 128 MiB.

[FranciscoPombal]

For anyone facing the issue, go to Options -> Advanced -> Disk cache and change from auto to 64 MiB or 128 MiB.

Just to clarify, this is a workaround for those using 4.2.3, and the exact amount can be even higher than 128 MiB, if needed. From 4.2.4 onward, which includes the libtorrent fix, auto can be used again.