Frustrated - slow download

[jeps]

My first impression is, that it is as slow as "normal"

I have 7 MB/7 MB allocated to the program, but even with popular Torrents with dedicated seedboxes the download speed is 1.5-1.6 MB/s.
I would have expected 6-7 MB/s.

Total max number of connections is set to: 500 (100 per torrent).

EDIT:
It seems like all connections is limited to 100 KB/s download speed?
(TCP connections, I don't have that many UTP at the moment).

EDIT 2:
It seems that UTP has no bandwith limit per connection.

Edit 3: 
Just added 1 torrent with only 1 seed (seeder using a seedbox running libtorrent 0.13.3) and I'm able to get 2 MB/s from just 1 connection.
This contradicts my findings in "Edit 1", but "Edit 1" was stable in this way (100 KB/s from each TCP connection) for more than 10 minutes.
And all ~6 "TCP seeders" each delivered 100 KB/s and 1 UTP connection delivered ~250 KB/s.

[sledgehammer_999]

Hmm, I didn't know that it was rate limited. shiki provides the space/bandwidth for this...

[Pyro]

I would like to test, but I've had horrible experiences with the 3.1 and 3.0.1.1 version in terms of stability. Can a version 3.2 be created with the 0.16.10 litborrent version? Last time I tested, 3.2 alpha x64! was running stable, but not very fast in terms of upload, though download was ok.
Sorry for any additional effort, but my mind couldn't take any more crashes on the older version since I'm highly unstable mentally and might destroy something valuable if it crashes again.
Thank you <3

[sledgehammer_999]

v3.2.x is basically the same as 3.1.x at this point of time.

Anyway I don't want to force you on anything. But if you are up to it, you could test with a VM and not destroy your real torrents.

[jeps]

I am left with the impression, that the issue in this thread is being neglected.
But why?

As you can see in my findings (posted earlier) something is not right.
If your troubleshooting says it is a Libtorrent problem,  please say so.

Anyway, I am stuck with version 3.0.11 for now.
Hope you get it sorted out!

[sledgehammer_999]

@jeps did you try the build I linked to ?

[jeps]

No, I didn't (sorry I missed it).

Will do so now - I'll be back

[dinjo]

I'm on 3.1.0 but on linux had no issues I guess it's probably due to type of client the seeder is having linux due to some reason is able to overcome this limitation

[sledgehammer_999]

@dinjo what version of libtorrent do you have installed?

[Nemo]

qBittorrent 3.1.1 with libtorrent 16.10 seems working much better than the ones build with 16.12 in terms of download/upload speeds, but need more people to confirm this. Lets wait what jeps (or others) have to say about it after testing that build. Mine is still running flawlessly (1 day and 3 hours straight).

Edit: I've transfered all my torrents now. Can download 2-3 torrents at the same time (I couldn't with 16.12) without any ''speed lag/drop downs/throttling''. No speeds issues or whatsoever. Still testing and awaiting others opinions/experience. qBittorrent 3.1.1 + libtorrent 16.10.

[jeps]

I have done some testing of this build now.
Until a few minutes ago, I actually thought the problems wasn't there, but...

I started a few downloads and all of a sudden I saw this problem with bandwidth limitations on TCP connections across torrents.
It more or less looks like a deliberate attempt to share the download bandwidth without the overall bandwidth limit being reached.

Which leads me to the question; Why must I have µTP bandwidth management enabled to use the µTP protocol?
I only want the "basic" functionality of the µTP protocol and not bandwidth management and "Hole punching" etc.
Is that possible?

[dinjo]

Code: Select all

root@debian:~# dpkg -l | grep libtorrent
rc  libtorrent-rasterbar6                 0.15.10-1+b1                       armel        C++ bittorrent library by Rasterbar Software
ii  libtorrent-rasterbar7                 0.16.11-2                          armel        C++ bittorrent library by Rasterbar Software
ii  qbittorrent-nox                       3.1.0-1                            armel        bittorrent client based on libtorrent-rasterbar (without X support)

[Nemo]

[quote="jeps"]
It more or less looks like a deliberate attempt to share the download bandwidth without the overall bandwidth limit being reached.
[/quote]

Thats exactly what im thinking. For me this build with 16.10 is working better than builds with 16.12 but something is (still) limiting the overall speed now and then, especially if you run 2 or more torrents (not too many). What you see is something like this: lets say your max is 500KB/s but the speed stays around 250-300KB/s more or less the whole time while it can go faster but it simply doesn't. Its almost the same like my tests on the previous page. Im not maxing my line either this way (which is much higher than 500KB/s by the way ). Seeding seems good but im still testing the download behaviour now so I will report back within few days how it goes.

[jeps]

As an experiment I tried to disable µTP protocol and I haven't seen the problem since then.
So it would seem (I think    ) that the "µTP bandwidth management" makes some bad decisions.

As mentioned earlier, I would really like to have µTP enabled, just not the "bandwidth management" part.

[sledgehammer_999]

As an experiment I tried to disable µTP protocol and I haven't seen the problem since then.

In which build?