Jump to content

! Finish Your Peases Before Ice Cream


Guest

Recommended Posts

Hi,

Please take a look at this picture, a snapshot of the pieces tab from three different torrents: utorrentpeas1sz.th.png

It shows that the pieces seem to be downloading in an unstable fashion. A lot of them are left incomplete. When transfers are initiated, new pieces are started instead of existing pieces being finished. This has been the way with pretty much every large torrent I've done, with smaller ones I get slightly squarer (?) piece distributions.

The first scenario is really bad because it increases the chances of data loss. If for—one of many—reasons your torrent ends up having to be rechecked, incomplete pieces are lost and have to be downloaded again. If you've got a LOT of them like in the former screenshot, your completed percentage will drop by quite a lot, especially since the large torrents that it occurs with most often tend to have many pieces, and large (2MB) pieces at that. One recheck and you could lose 100MB!

I've propsed allowing the user to prioritize pieces in this thread which could allow the user to prevent loss and it has other uses as well so it would be a great feature. However, µTorrent should on it's own (automatically) try to finish incomplete pieces first.

µTorrent needs to finish the peas (incomplete pieces) before moving on to the ice cream (new pieces) because just as with dinner, it's better for you/us/me/he/she.

Link to comment
Share on other sites

the problem with that is the performance loss of the torrent, what if the single part the piece needs to be complete it's that of someone who left the swarm? or that has the torrentr paused? there is no control in how you can complete the pieces, you of course can give priority to some pieces but there is no way to say that is going to work, it starts new pieces as it cannot just stay there waiting one to be completed, do u prefer to stay downloading at 0kB/s by 15 mins, just because the "rare piece" isnt finished yet?

instead utorrent starts new pieces not to lose speed, and anyway eventually the pieces will finish

if u are suffering from data loss, that is another problem, and surely shouldnt be happening and u should take a look at that, and of course, if u know a re-check can cause 100/200MB data loss then why would you do the re-check? it is supposed to be used really rarely anyway, not every hour or whatever, so u shouldnt suffer of data lost, if u instead have another file that could add more pieces to the torrent and dont want to waste data, then skip the file until the rest of the files are finished and then do the re-check to complete the torrent

BTW, prioritizing pieces would harm the swarm, just as prioritizing the files always does, and we dont want that do we? :P

Link to comment
Share on other sites

I'm talking about pausing the whole thing until an existing piece can be completed, I mean the BT client should make a best effort to do so.

When I said data loss, I didn't mean hash fails, I mean like if the power goes out, a BSOD occurs, or some other event that prevents µTorrent from saving it's progress.

Link to comment
Share on other sites

In the time that it takes to complete that one piece that seems to be stalled, I'm pretty sure you'd have completed many other pieces already. This doesn't happen occasionally anyway, and downloading whatever pieces you can when they mostly finish saves more time than not redownloading a few lost pieces from those relatively rare hypothetical situations. If they're not rare occasions, then you've another problem on your hands that you should be more worried about.

Link to comment
Share on other sites

So until 1.5 utorrent has been hurting the swarm? I don't think this option should be completely removed, maybe min pieces should be ~20 or sht like that, because sometimes PC crashes, and if it would crash when you've partilary downloaded 50pieces of 4-8MB i wouldn't like it because i have low dl speed, and I'm not the only one here with such speed.

Actualy it would hurt the swarm even more, since you have to redownload big amount of data and not all people will upload more on that torrent.

Link to comment
Share on other sites

Well removing an option to reduce amount of pieces downloaded is not bad thing, but it would be good ir utorrent limited max amount in MB, and if that amount is reached it would not start new pieces or smth, because there's no use if it partilary downloads 200+MB and can't seed it since pieces are not complete. Don't you think so?

Link to comment
Share on other sites

An indirect side-effect of this problem is on posioned torrents or torrents with peer/seeds with bad routers (D-Links in 'gaming' DMZ mode).

With lots of chunks not getting completed quickly, determining who sent you bad data is much harder.

It's ok to have multiple peers/seeds send you multiple chunks. The problem is when they send you a tiny piece of a chunk and then they get requests from µTorrent for OTHER chunks, so they never end up completing any particular chunk in a timely manner...which gives hostiles and unintentional corrupters more chances to send you garbage data.

Link to comment
Share on other sites

  • 1 month later...

I have quite an opposite problem altogether. My machine often ends up downloading a single piece so single-mindedly, and that piece happens to be poisoned. (I imagine the poison might have falsified the rarity signal.) So the torrent never gets anywhere because it keeps downloading the poisoned piece. If I could at least tell the client to postpone that piece until later and move on to other non-poisoned pieces, it would help a lot.

Based on what I've seen over many months, mostly there are only a few pieces that are poisoned (i.e. consistently fails hash check even though you've banned a gazillion of IPs) and if left alone long enough, you'll end up with a 99.8% torrent with only that piece remaining, and eventually the poison goes away and you complete it. If you postpone this in the first place, it'd save a lot of bandwidth for everyone.

Link to comment
Share on other sites

One should never insist on finishing certain piece manually. This should be left to program (BT client) to decide what piece to prioritize since it keeps statistics etc. on possible speed/availability/my connection speed/blah blah. I believe µTorrent is pretty good at it. You should have seen Azureus on my comp opening a 70+ pieces, each with only one block of 16KB downloaded - it lead nowhere after 20 mins of downloading.

However, this is somewhat related with my request from few days ago for finishing started pieces before (http://forum.utorrent.com/viewtopic.php?id=10264)starting new ones, and I'd like to state something I discovered:

If you have some started pieces, and then manually set all files to NOT download, but keep the torrent started, µT will finish all those started pieces, and then turn itself in seeding state (only uploading). This is exactly what I wanted, and would like to know if this is some kind of side-effect, or left on purpose. I tried this a couple of times and it always acted like that.

Since my request is already fullfilled :), could you implement re-checking without losing the open pieces progress? I know it doesn't make much sense, but could be very good time-saver...

Link to comment
Share on other sites

However, this is somewhat related with my request from few days ago for finishing started pieces before (http://forum.utorrent.com/viewtopic.php?id=10264)starting new ones, and I'd like to state something I discovered:

If you have some started pieces, and then manually set all files to NOT download, but keep the torrent started, µT will finish all those started pieces, and then turn itself in seeding state (only uploading). This is exactly what I wanted, and would like to know if this is some kind of side-effect, or left on purpose. I tried this a couple of times and it always acted like that.

Since my request is already fullfilled :), could you implement re-checking without losing the open pieces progress? I know it doesn't make much sense, but could be very good time-saver...

Yup, you're right, this is closely related to your post; in fact I have had the problem you posted about often. The point is that we would like to eliminate or at least reduce the amount of loss in the even that something goes wrong.

I still think that allowing the user to select per-piece (per-block? :P) priority would be good. Obviously it would not be used often or at all by most people, but in some situations, it can be a lifesaver (can help avoid having to redownload hundreds of MBs which is bad for everyone.) My biggest problem is with piece size. With small pieces, it's not a big deal. If you lose 40 128KB pieces, you lose only 5MB which is tolerable. But if you lose 40 4MB pieces, you lose what may have been a whole week of downloading! :o

It would help if the user could set the update frequency, preferably per-torrent. So for example, you could leave a popular torrent with 128KB pieces to the default while setting a 1GB torrent with few seeds and 4MB pieces, to update every 30 seconds (or just set µTorrent to do it every 30 seconds period.) That way you don't lose much if some app forces a restart (not all prompt you), or the power goes out, Windows crashes, or a multitude of other things happen (older versions of µTorrent used to force a recheck on startup everytime it was shutdown with Windows instead of manually).

As for not losing half-done pieces on recheck, that's been a thorn in my side for a long time. Unfortunately there's not way to do it unless µTorrent implements per-block checking. That's going to have to be a seperate request. :)

Link to comment
Share on other sites

  • 5 months later...
  • 5 months later...

Forget about the piece completion thing, what about SAVING the incomplete pieces? If a recheck has to be done, why do the incomplete pieces get discarded? Can't µTorrent wait until after the recheck is done, then throw away any incomplete pieces it doesn't need anymore, and keep the ones it does?

Link to comment
Share on other sites

That makes sense, but there are more reasons for a recheck than corrupt pieces. From what I can tell, partial piece information is stored in resume.dat along with torrent progress right, so you can't just backup resume.dat before rechecking and restore it after?

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...