Jump to content

Unusual behaviour in priority system


foomonger

Recommended Posts

The admins here seem to lack a sense of humour, so I'll post this here, instead...

This is a "behaviour" which has affected every version of uTorrent (including the latest beta). Priorities...

I often download whole seasons of TV shows, and obviously, want to see them in order, so make great use of the high/normal/low priority settings that uTorrent provides. It's a great idea.

But once again, tonight, I find myself sitting, for almost an hour, waiting to download a single chunk to complete the next episode (damned two-parters!), while chunks from other episodes tear down at lightening speed. I can actually see the bar zip along for episodes with normal priority, low priority, even episodes I've told to skip, while the piece I want sits there, doing nothing.

It seems insane, paranoid even; but I've watched this phenomena literally hundreds of times in uTorrent; it's like uTorrent knows that I want it (by my settings) and is messing with me. I've sat, watching the pieces view, with fifty or more pieces from episodes that are set to low, even skip, go from 1 chunk all the way to 256 chunks, while the episode I've set to high priority sits, the entire time, at 255 pieces, laughing at me!

Even if the piece I want has the highest availability, it makes no difference; uTorrent will NOT grab it. It would take seconds to complete, but uTorrent refuses to do it, until it totally, absolutely has to, when all the other pieces I don't want are downloaded. It's infuriating!

Also, just to annoy, uTorrent likes to ensure that pieces I don't want any time soon are invariably in fast mode, while pieces I do want are set to slow mode. lol

So, is all this on purpose, or a bug, or what?

-fm

ps. Aside from this, uTorrent is by far the best torrent client on any platform, and so long as you aren't waiting for the next episode of something; a joy to use.

pps. chunk 256 is STILL not down!!!

Link to comment
Share on other sites

Yup, I know how to use a Torrent client, thanks!

Setting a file to "skip" makes no difference whatsoever; if uTorrent has begun a piece, it must complete it (that's part of the BitTorrent Protocol, I assume). That behaviour is expected. What isn't expected is that it will download that piece before pieces I have set to "high" priority.

I explained all this in my original post.

-fm

Link to comment
Share on other sites

Correct; it was trashed; so this isn't double posting, is it?

And what is more rude; posting this information again (because I cannot reply to threads in the trash, even when others have), or trashing a well-written post about a real issue? By the way, that's rhetorical.

Anyways, if anyone actually knows why this happens in uTorrent, I'd still very much like to know.

-fm

Link to comment
Share on other sites

Well to answer part of your question since I can't PROVE the 255/256 to you, fast/slow mode is based upon the peers upload speed to you... usually when you're getting it from a seeder with > 10 KiB upload it's fast, sometimes it's in slow mode... generally PEERS with > 10 KiB upload to you it's slow.

Double posting is when you create a(n) (near-)identical thread to existing content... ie when you http://forum.utorrent.com/search.php for relevant keywords BOTH threads show up. The oldest thread is kept, and the newer ones are trashed.

Link to comment
Share on other sites

Normally, I don't use "skip" except as a last resort. However, earlier today, as an experiment, I set two episodes of my current torrent to "skip". Everything else is set to "normal", except the "next" episode I'll watch, which is set to "high".

There was a single piece left in the next episode (the one set to "high"). This piece hadn't been started, and was blank. The episode was at 98.8%.

At this point, I set one of the skipped episodes to "low" priority. Within seconds, the low priority episode has three active pieces, while the episode set to "high" remains at 98.8%, and its final piece remains blank. That piece didn't start until almost an hour after that; by which time, the episode set to "low" has completely downloaded dozens of pieces!

Call it what you will; but I call that "broken".

-fm

Link to comment
Share on other sites

Probability...if low and high are only 1 magnitude different in chances of something occurring, then a file at high missing 1 piece and a file at low missing 10 pieces will each gather about the same amount of attention assuming nearly equal piece rarity among peers. BUT...the high file's single missing piece didn't complete earlier precisely because it was considerably rarer among peers. So it is NOT surprising that 10 or more pieces in the low file completed before the high file got its last piece.

Your torrent swarm was probably "broken"...with various peers running sequential downloading, high priority on some files and low/don't download on others, as well as badly-configured and slow peers+seeds that refuse to upload at a reasonable speed -- or do so intermittently only...causing piece downloads to stall.

With the long download limited wtf? v1.8 complaints thread to go by, there is a SHOCKING number of people that set their upload speed to only 1 KB/sec on their downloading torrents. With small torrents that's bad, but large multi-file torrents it is a disaster. Worst-case it causes uTorrent to vastly miscalculate how rare pieces are...because uTorrent "sees" peers with pieces and presumes (at least initially) that each piece seen reduces rarity by an equal amount, even when "shared" by a peer that is uploading nearly nothing. Before utorrent is done downloading such a torrent, it's typically exhausted the easy-to-get pieces and is now waiting on a few very slow peers to finish uploading the rarer pieces. This means download speed drops off towards the end to lower than it was when first starting the torrent. (Especially the 1st 15minutes when you have little-to-nothing to share.)

Link to comment
Share on other sites

In my experiment, the episodes that were set to "skip", were much later, sequentially, in the viewing order, so the "swarm is broken because of sequential downloading" theory can't account for uTorrent's behaviour there. Also, availability was not the issue; the piece that I waited (and waited) for had a higher availability than any other piece I was currently downloading (by quite a margin; something the sequential downloading theory *does* account for!). But even if all the available copies of the piece I wanted were held by peers with 0.00000001KB/s upload speeds, it wouldn't matter, uTorrent wouldn't even start them up.

In case anyone wasn't paying full attention, I have; over the course of this thread; outlined two separate issues; both identical in operation; one at the piece level, and another at the chunk level.

Perhaps the problem is simply that a magnitude of 1 is nothing like enough! 1000 would be closer to what I, as a human not a computer, would calculate as the difference between tasks of "high" and "low" priority. In other words; I would expect that for every 1000 connection attempts my torrent client makes, 999 of them would be attempting to obtain the high priority piece.

A slider in the preferences would be ideal!

I do agree about the disgraceful upload speeds that are becoming common in swarms. wft, indeed.

-fm

Link to comment
Share on other sites

Meh, it's not as if µTorrent simply says "I don't want this piece." µTorrent is at the mercy of other peers, and if they don't send the piece, then there isn't anything µTorrent can do get them to send it. At the very end, µTorrent jumps into endgame mode, in which case it requests the remaining piece from every single peer it's connected to (instead of the usual one-at-a-time), which is why it finally downloads.

Link to comment
Share on other sites

  • 6 months later...

It would be better if there were a shorter 'timeout' period on a chunk/piece before uTorrent attempts to download the same chunk/piece from other peers/seeds. Attempting an 'endgame' mode with each file in a busy many-file torrent would only result in mad amounts of wasted bytes.

Link to comment
Share on other sites

I think this is not about implementing timeouts on arbitrary pieces. It's about multi-file torrents and users waiting for a high priority file to finish downloading the last couple of pieces.

In a multi-file torrent the priority system (high, normal, low, skip) works very well until the last chunks of the last pieces of a high priority file. Then often this file will just not finish (for reasons unknown to me). It gets stuck on the last pieces. As a workaround I restart those torrents (sometimes even setting all other files to "skip"). Then the file will be finished in a matter of seconds.

Link to comment
Share on other sites

Switek, thanks for explaining. I would not argue against this behaviour if I could manually intervene. E.g. right clicking on a stalled piece and selecting "try other peers". Of course, I'd prefer a programmatic solution to this issue as those solutions tend to be torrent friendlier than manual interference.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...