This is a very recent example, where downloading a 1.1 GB file wasted almost half the time at the 99.9 % stage, reducing the effective download speed by 50 %:
It seems to me that a relatively simple algorithm could resolve this.[21:00:00.155] Progress: 0.4%, dl from 11 of 60 peers (19 KiB/s)
[21:02:00.155] Progress: 5.6%, dl from 10 of 60 peers (2230 KiB/s)
[21:04:00.155] Progress: 34.9%, dl from 11 of 60 peers (1621 KiB/s)
[21:06:00.185] Progress: 64.3%, dl from 11 of 60 peers (1885 KiB/s)
[21:08:00.155] Progress: 93.3%, dl from 17 of 60 peers (1874 KiB/s)
[21:10:00.165] Progress: 99.9%, dl from 14 of 60 peers (7 KiB/s)
[21:12:00.165] Progress: 99.9%, dl from 4 of 60 peers (0 KiB/s)
[21:14:00.175] Progress: 99.9%, dl from 4 of 60 peers (0 KiB/s)
[21:16:00.175] Progress: 99.9%, dl from 5 of 60 peers (0 KiB/s)
[21:16:28.219] State changed from "Incomplete" to "Complete"
At the stage where there are no remaining pieces not actively being transferred, request slow pieces in duplicate from preferably known fast peers, alternatively simply drop the download connection to extremely slow peers. In fact, dropping the download connection to extremely slow peers (say < 5 % of the average peer download rate) might be a good strategy at all times, freeing up both download slots for the client and an upload slot for the peer.
Thoughts?