Option to choose initial choking alorithm

Discuss suggestions and ideas for the forums, site, software.
Post Reply

Would you like to choose the initial peer choking algorithm (read the thread first please)

Yes
3
75%
No
1
25%
 
Total votes: 4

ciaobaby

Option to choose initial choking alorithm

Post by ciaobaby »

With reference to this thread and this information;
seed_choking_algorithm controls the seeding unchoke behavior. The available options are:

    round_robin which round-robins the peers that are unchoked when seeding. This distributes the upload bandwidht uniformly and fairly. It minimizes the ability for a peer to download everything without redistributing it.
    fastest_upload unchokes the peers we can send to the fastest. This might be a bit more reliable in utilizing all available capacity.
    anti_leech prioritizes peers who have just started or are just about to finish the download. The intention is to force peers in the middle of the download to trade with each other.
from the libtorrent API documentation http://libtorrent.org/manual.html

Currently qBT uses the default algorithm of "round_robin", which means that for seeding to start the swarm size must be a minimum of three nodes, 1 seed 2 peers so that pieces can be served to alternate peers.
For seeding to start with a swarm of two (1 seed, 1 peer) the algorithm must be set at "fastest_upload"  or a BEP 19 webseed must be defined in the meta data to operate as an "unchoked seed"

None of this matters if you are making your torrents available to multiple peers and three or more start to download but if only one other peer is "interested" the job WILL stall after one or two pieces have been completed. Also stalling will  occur if the connected peer count drops to only one after the job completes, such as with overseeded jobs on 'private' trackers.

Proposal: To make the choking algorithm selectable, globally rather than for individual tasks to minimise the effect on the footprint.
ciaobaby

Re: Option to choose initial choking alorithm

Post by ciaobaby »

Git #1938
gwarser

Re: Option to choose initial choking alorithm

Post by gwarser »

If this is true, then should be treated as libtorrent bug
ciaobaby

Re: Option to choose initial choking alorithm

Post by ciaobaby »

It's not a bug, as it works correctly and as designed, it is simply that qBT uses the round_robin algorithm option by default, and has done since day one. The simple fact is that nobody seems to have noticed or investigated previously.
sledgehammer_999
Administrator
Administrator
Posts: 2443
Joined: Sun Jan 23, 2011 1:17 pm

Re: Option to choose initial choking alorithm

Post by sledgehammer_999 »

This either is a libtorrent bug or the docs need clarification on what round_robin does (ie the limit of 3 peers).
So I created this: https://code.google.com/p/libtorrent/is ... ail?id=676
gwarser

Re: Option to choose initial choking alorithm

Post by gwarser »

If I understand correctly round_robin, fastest_upload and anti_leech are only SORTING algorithms. They sort available connections by some priorities - thats all. (session_impl.cpp line 5187 in trunk)
Last edited by gwarser on Mon Sep 15, 2014 7:01 pm, edited 1 time in total.
ciaobaby

Re: Option to choose initial choking alorithm

Post by ciaobaby »

[quote="gwarser"]
If I understand correctly round_robin, fastest_upload and anti_leech are only SORTING algorithms. They sort available connections by some priorities - thats all. (session_impl.cpp line 5187 in trunk)
[/quote]

Yep, they set the 'priorities' but bittorrent engines handle priorities and queues by 'choking' peers that are 'interested' but are not allowed to download, take a look at the protocol specification on choking
Dayman

Re: Option to choose initial choking alorithm

Post by Dayman »

I doubt average users go into advanced settings, so we might just change the default. Or we could put this into Bittorrent section of config with meaningful descriptions users will understand.

P.S. Been using fastest_upload for like half a year.
ciaobaby

Re: Option to choose initial choking alorithm

Post by ciaobaby »

P.S. Been using fastest_upload for like half a year.


Excellent, that would save me rooting through the labyrinth of curiously named  things that all begin with Q :)

Sometimes I think I'm reading a plot for a Star Trek Next Generation that features John DeLancie
AsaRossoff

Re: Option to choose initial choking alorithm

Post by AsaRossoff »

My vote is "No" :)
* Short and simple, there is one algorithm that is ideal for the network (one when its implementation scope considers both general issues and specific-to-swarm issues, perhaps including number of peers, availability of pieces, etc., etc.).
It has been a matter of study, I realize, and it is a complex question as to exactly what choking algorithm is best for the network.
But whatever is deemed best for the network is best for qBittorrent in my view.  If it's best for the network and everyone is using it, it's also best for the user.

My gut tells me that whatever complex priorities may be taken into account, all my upload bandwidth should be used one way or another, if at all possible.  Obviously peers can be blocked with cause, though.

* I would think that any choking algorithm that chokes every (e.g. the only other) peer is broken, unless they need to be blocked.


However, related is the global queuing, prioritization, and bandwidth management among all torrents.  I do not know how the choking algorithm setting applies among multiple torrents, if at all.

I'll mention that I do have an issue with current behavior when multiple torrents are uploading.  Typically in my case, many are uploading and one or at most two are downloading.
I believe this issue involves both the choking implementation (I do not know if the outcome would be different with different settings) and the prioritization of multiple uploading tasks:
* In my described use case, if there is any upload demand on complete/seeding torrents, there is virtually no upload activity on the currently downloading torrent until it completes, at which time, it suddenly takes on what appears may be the highest of priorities for uploads!  If anything, this is the reverse of what I would expect.  I would expect uploading while downloading to either be the highest priority or at least prioritized according to the same criteria as seeding torrents.

To work around that, I label the torrents I will continue seeding when the download completes, and pause all torrents except rare torrents where I am the only/one of a small number of seeders and there are no fast peers on them at the moment :).  Later, I relabel and restart the torrents I paused when the download(s) complete.


Thanks ciaobaby for noticing this and raising the issue.
ciaobaby

Re: Option to choose initial choking alorithm

Post by ciaobaby »

Short and simple, there is one algorithm that is ideal for the network (one when its implementation scope considers both general issues and specific-to-swarm issues, perhaps including number of peers, availability of pieces, etc., etc.)
You are absolutely correct.
Unfortunately the default of a  "round-robin" algorithm fails completely in a swarm that has less than two actively downloading peers.

Consider the scenario of:
You are the only seed with two peers actively downloading, one is at 95% the other at 20%, when the first peer (95%) reaches 100%, ALL downloads stop because the round-robin algorithm 'chokes' the 20% peer because there are no other downloading peers to rotate piece delivery to.

The "rarest piece first" algorithm also fails in this scenario because ALL pieces are equally 'rare' and the seeds will not respond to requests until another TWO peers arrive on the scene.
sledgehammer_999
Administrator
Administrator
Posts: 2443
Joined: Sun Jan 23, 2011 1:17 pm

Re: Option to choose initial choking alorithm

Post by sledgehammer_999 »

If arvid doesn't respond to the issue, maybe we should change to fastest_upload for v3.2.0.
The description makes it seem almost identical to round_robin with a bit of bias to fast peers.
Muzak

Re: Option to choose initial choking alorithm

Post by Muzak »

I would vote for that change, only because a couple of my favorite private trackers frequently have only one or two peers on a regular basis for some reason.  Makes sense to have the default be the one that handles the lowest common denominator.
Post Reply