Normal prioritized files finish before highly prioritized ones ?

[ezalo]

I have noticed this a long time ago, even before the new fine grained scheme for priorities.

The actual scenario is a torrent with multiple files, one with high priority and the others with low or normal priorities. The torrent is being seeded with either slow and fast peers, all of these with 100% of torrent parts.

The last part of a high prioritized file begins to be downloaded from a slow peer and the other parts on the remaining files from fast peers. Whenever the high prioritized file is being assigned to a slow peer (seems to me that is 1 only), the other parts begin to be downloaded from the remaining (possibly faster) peers and sometimes files with low priorities finish first.

On the other hand, when the last part of the last file is being downloaded, utorrent seems to employ an alternate scheme of having more than one peer assigned to that part in order to finish it as fast as it can.

Imho, it seems to me that the last part of the highest prioritized file should be treated like the last part of the last file being downloaded.

Is it correct?

utorrent 2.2 beta build 22328

[Ultima]

Maybe I'm not understanding you here, but I'm not seeing what the problem is. Priority doesn't guarantee anything about the order in which a file is finished. It is a guarantee that µTorrent will attempt to get data for a file more insistently from other peers. If it so happens that you run into bad luck and request pieces from slow peers, then you might end up stuck -- there isn't a whole lot you can do about that, and that isn't a bug.

To combat finishing files getting stuck, µTorrent employs end-game mode on a per-file basis (where it requests data for a single piece from multiple peers), but that invites additional overhead and wasted bandwidth (redundant data sometimes), which is why it isn't done throughout the download process.

[ezalo]

I see, Ultima. Not a real bug since utorrent does't crash.

I was thinking more properly about the strategy of prioritization on a "finish it as far as you can" basis. Note that this is what utorrent does in almost 100% of the cases.

Whenever one file is highly prioritized in comparison with the others (for instance, 3 files, high-normal-low priorities), parts are barely downloaded for files with lower priorities. When the first file finishes to be dowloaded (considering "downloaded" with some of the last parts still being downloaded from slow peers), the strategy described above is applied to the remaining files. Thus the prioritization scheme can fail on the basis utorrent proposes to work (as stated in last paragraph).

The end-of-game strategy you talked about could be applied for these parts or, while torrent is far from being completed, slower peers could be reassigned for some parts of other files.

Finally, sorry about placing this post at a wrong place. Trash it and I'll try to rephrase it and post it in other section.

Thanks for your attention

[Ultima]

Well, it doesn't have to be a crash to be a bug, but yeah, at this point it looks like it's behaving within reasonable expectations.

Just to be clear, µTorrent doesn't download the remaining pieces slowly because it gets stuck -- it gets stuck because the remaining pieces are getting downloaded slowly. That is, it doesn't always finish a file completely (regardless of priority) because the pieces it can't get are hard to get, and that's why it was left to the end. µTorrent doesn't get to pick and choose what peers it gets data from -- it requests a piece from a peer, and if that peer responds with the data, µTorrent accepts. It's not simply a matter of reassigning peers.

And no, end-game mode shouldn't be used at any time it seems convenient (i.e. just because it looks like a piece is downloading slowly). As already stated, it incurs wasted bandwidth, so the apparent speed boost you see isn't necessarily µTorrent downloading the piece more quickly; it could just be µTorrent wasting bandwidth trying to redundantly request the same exact data from different peers in hopes that at least one of the peers will respond appropriately. It doesn't make sense to waste bandwidth unless it's known that there is no other way to finish up the file in a reasonable amount of time. Even if a piece is downloading slowly, other pieces in the file are (presumably) still being downloaded in parallel, so you won't reap any benefits from trying to finish any one particular piece more quickly until you're at the end of the file's piece pipeline, which is where end-game mode takes over.

[ezalo]

I've being observing the way utorrent administrates the downloads. In my mind, higher priorities mean higher probabilities of being downloaded. Except for the last part of a particular file, before the torrent completion, utorrent works perfectly in this way.

I still think that the strategy for the last part can be aprimorated, as it's a recurrent subtorrent of the whole. In particular, when I'm in a hurry for looking some file being downloaded, 'locked' by a slow peer, I stop the torrent and continue immediately. Instead of doing this, I would prefer utorrent to automatically request to another fast peer that part and to assign the slow peer to any other part. No way to exclude overheading even with this scheme, also.

That's it. Sorry by the messes. I'm completely ellucidated. Thanks, Ultima.