An overview of all options can be found here.
For discussions, please come to the Forum.
Endgame mode:
Instead of a normal endgame, something different is implemented, because observation of download behaviour shows that endgame mode is difficult to trigger properly, i.e., at the end, any trigger algo will either lead to overly eager block requests or a considerable slowdown of download.
Instead of a global endgame, we implement a per peer endgame: we start such an endgame when the request queue of a given peer cannot be filled with the normal method. Whenever there are request slots left that are not filled because possible block requests have already been sent to other peers, we will simply fill the queue by redundantly requesting blocks already requested from other peers. In the very end, this is like a normal endgame, by starts dynamically for each peer, it prevents slowdown at the end, and it takes into account what peers have.
Since this local endgame might bombard peers with only few pieces, because their request queue cannot be filled, we will constrain the local endgame by another global condition, similar to that of the normal endgame: we start local endgame only if we lack at most as many blocks as we have request slots, times 2. So we start global endgame earlier (by a factor of two), but when we start it, we only start it locally for a each connected peer. Hopefully, this results in a more stable download at the end.