Priority Level

[7539518624]

When you go to the files tab and you can set the priority level from low, normal or high.

Can you set it to do file by file instead of download all at once.

[Alexander_Q]

At this stage you cannot, and there is discussion about whether enabling an option like this would harm the swarm in general. One suggestion is to select "do not download" for all files but one, and then when it finishes, change another to high priority and resume the torrent.

This requires you to continuously monitor the torrent, and also is harmful to the swarm because others are trying to download the whole torrent all at once, but it is one way to do it.

I tend to just set everything to low priority except for the next file in, for example, the TV series I am watching. When the first finishes, I set the next to high priority and watch the first, and by the time I'm finished, it's time to set the third episode to high priority. This method isn't so damaging to the swarm because pieces are still being downloaded for all files.

[7539518624]

thanks that is what i will do yea i am downloading tons of series

Right now stargate atlantis then star trek deep space nine and next generation

[Alexander_Q]

Christ, you've got your work cut out for ya. Next generation will be quite a task. What's your connection?

[salteris]

My idea of 'high' priority is that it should be actioned before a lower priority items unless it just can't be done, but uTorrent doesn't seem to work this way.

I found that setting a specific file to 'high priority' with others at low priority doesn't usually result in ALL blocks of the high priority file being downloaded with any apparent priority. A few blocks seem never to start while there are others to get. So.....

With a big torrent that has lots files, I set one file to high, a few others to low and the rest to 'skip'.

When I get tired of waiting for the last of the priority file to complete, I set all other files to skip (which still keeps downloading the started pieces of of those files).

When the active pieces (those downloading) complete and there's only a few pieces left (like 4 - 6), uTorrent then starts on the missing pieces of the high priority file (the only remaining 'non-skipped' file).

After this happens, it's fine to re-enable the part-downloaded, low priority files, set one of them (the next you want to use or just to have completed) to high priority, and add a another file to the low priority set to be started. And so on...

--- well it seemed simple before I started to describe it.

[Ultima]

File prioritization skews piece distribution. Just because µTorrent has a file in high priority doesn't mean it should exclusively download pieces for the file. That would further aggrevate the piece distribution skewing, and would also slow the transfer rates down (slowing the entire swarm down overall).

[salteris]

Ultima - not what I suggested.

- Forcing download of the last few pieces of a file 'sooner than never' isn't saying exclusive download.

- Not downloading the last few pieces of a file isn't going to help much in the grand scheme of piece distribution.

As it stands, by "skewing piece distribution", the damage to download dynamics has already been done.

I guess I could prompt you with a couple of questions -

...what's the value of having a high/normal/low priority of file download if the ultimate completion time of the file is unchanged?

...why get all serious about how the uTorrent option might effect swarm efficiency if the true control is still with the nasty users to force download sequence via the skip files method?

I admit that when I download files from within a large torrent, I do have the greater good of mankind at heart and select random files to complete with priority (I already have a medal thankyou).

The wish to complete files is mostly my irrational fear that the availability of the torrent is going to fall apart before I'm finished, leaving me with an extensive amount of useless bits.

How about another naive idea - what if the priority change option just displayed a message to tell the bunnies that "changing it could negatively impact download dynamics" (skipping all the waffle about existing piece availability for the torrent), and then uTorrent could throw all caution to the wind and just download that last pesky 4MB...

[Ultima]

When you tell µTorrent that a file is a higher priority than another file, it tells µTorrent how it should request the pieces for that file. That doesn't mean it tells µTorrent how it should download the pieces. What tells µTorrent how it should download is what the other peers actually offer. If µTorrent has a file at a higher priority, it'll more actively request pieces for that file than a lower priority file. Other peers will receive requests for those pieces more often, but that doesn't mean they have to act on it. Those other peers can choose to honor the requests if they so wish, but it's not required of them to do so. If they don't, then the end result is that the priority settings just appear not to work. The last pieces always look like they're not downloading because... well, they're the last pieces because the peers weren't sending them in the first place

In short, µTorrent does as it's told to do, but the it's ultimately outside of its control. I've tried the priority settings on swarms that have a high level of availability and plenty of seeds/peers, and it worked fairly well; µTorrent finished the higher priority files more quickly than it did the lower priority files. The efficacy of the file priority settings is often a matter of luck in getting cooperative peers and a healthy swarm.

As for getting serious about swarm efficiency, I guess the point I was trying to make was that the regular, non-skip priorities should not behave like skip/don't skip relative to each other (but as you've already said, it wasn't your point, so oh well).

As an aside, I notice my reading "skills" have gone down the drain today. After re-reading your first post in the 1.7.4 release announcement thread, I realize my possible misunderstanding. Apologies for that.

[salteris]

OIC - that explanation does make the situation clearer. I did notice that higher priority files did tend to download faster, but as mentioned before, was still peeved that nothing made much of an impact on finalising a file.

In considering the explanation I was prompted to reconsider why I was trying to achieve a higher priority download in the first place.

The principle I'm now offering for consideration is that files which have downloaded an extensive proportion of their data amount to a greater investment for the user as there is more to lose if they don't complete.

- and as you've explained, the missing pieces of such files are likely to be the most difficult pieces to obtain - that being why they're the missing pieces.

However, I've noted that there must be some sort of action taken by µTorrent to overcome this problem when it's trying to finalise a download (does it cancel previous part requests and target other seeds/peers with equivalent requests until it gets prompt action?) because it manages when it really has to at the end.

So, perhaps this is finally something for a dev wish list -

can the finalisation steps for a large file part be triggered when its download reaches some predermined level - maybe 95% - rather than only when the torrent runs out of alternative parts to action?

And yes Ultima, I did think you took my stirring more seriously than I had intended, but I also thought it was a lesson for me to be a bit more circumspect in new spheres where such misunderstandings are likely. Another day, another lesson

[Ultima]

When µTorrent nears completion of the torrent, it enters end-game mode, where it sends requests for missing data to every peer (as opposed to sending a request for a piece to one peer per piece), and that's how it attempts to speed things up.

Basically, you're asking about something like an end-game mode per file (instead of per torrent), right? End-game mode is somewhat of a messy solution because it generates more noise in the swarm. Luckily, it happens only near completion. If it happened on every single file (or even just the large files), then as far as I can tell, it would cause a LOT more overhead (which is undesirable).

I'm not sure if the idea has been requested before, but it sounds vaguely familiar. Either way, though, µTorrent already tries to request what it determines to be the rarest pieces in the swarm (as many/most BitTorrent clients do -- or should do). I think this is probably the fairest solution, as it doesn't just "spam" the swarm with requests so often or at such a large volume as end-game mode might do. Dunno :/

(The aside) Smileys are key, I guess Because of the overall serious tone of the beginning of your first post, I never thought to mentally insert smileys near the end, which caused my misinterpretation. With so many people having visited the forums requesting eye-candy, I've become accustomed to blurting out those kinds of responses XD