set_piece_deadline() vs sequential_download

[AllSeeingEyeTolledEweSew]

From my understanding:

• set_piece_deadline(): for each time-critical piece, request that piece from the fastest-available peer
• sequential_download (now set_sequential_range() in master): for each peer, request pieces according to sequential order

Is my understanding correct?

If so, is there guidance on when/how to use each strategy, or combine it with others?

[AllSeeingEyeTolledEweSew]

Having read through #4408, I'll attempt to answer my own question.

Putting them both in terms of managing peer request queues:

• sequential_download: every time a new slot opens in a request queue, we just request the next piece in the sequence
  • Low complexity
  • Request queues stay full, so download bandwidth stays saturated
  • Pieces complete roughly in order
  • ...but there are lots of non-optimal cases, where early-sequence pieces might be requested from slow/bad peers
• set_piece_deadline(): does more work to ensure critical pieces are in the "optimal" queue positions, judged across all request queues
  • Early-sequence pieces more likely to arrive in desired order, versus sequential_download
  • ...as Clarification about Sequential mode #4408 mentions, we could do even more to maintain an invariant of "optimal" queue management, like cancelling requests

Is this a good description?

[arvidn]

yes, that's a good description. The time-critical piece picker is described in more details here: http://libtorrent.org/streaming.html
I think the current implementation has 2 issues; (1) it may not fill the request pipeline enough to maximize the download rate. (2) it may not accurately discover the download rate potential from peers by not sending enough requests to them, causing them to not receive many requests because they're slow.

[AllSeeingEyeTolledEweSew]

Are those issues the reason for #6262, or part of the reason?

[arvidn]

I think that patch may mitigate point (1)