Starting a new download a little before

[Tensk]

Hi!

I'm new here and I've registered since, after doing a rough search through the forum, I didn't find what I'm requesting. Chances are I'm wrong but...

I guess the subject is, at least, half explanatory but allow me to explain it better.

Let's say you have a certain number of downloads D1, D2, D3, ..., DN, some of them currently downloading CD1, CD2, CD3, ..., CDM (with M<N, and I really mean "<"), and some of then currently waiting CW1, CW2, CW3, ..., CWP (also with P<N and so that M+P=N... not too hard to imagine, I know). I guess this is a typical downloading list.

Well, the thing is that let's imagine that one of the elements in the CD-list is about to finish (as the Estimated Time column says if you've set it viewable, and I guess most of us do so), and finally finishes in that estimated time (or so). Well, in that moment you have CW1 becoming CDM (that is, the first one waiting becomes the last of the downloading ones), with all the usual things such as connecting to the tracker, searching for peers, seeds, leechers, and all that stuff, you know.

Well, the matter is that, in that time, all the other CD's from CD1 to CD(M-1) have already shared all the "freed bandwith" left by that downloaded item, so that new Current Download has it kind of worst to get some speed initially.

So, my request, as all those of you who have made it here will be guessing, is making the CW1 start just a little before (I propose it as a user configurable feature) that "almost finished" download actually finishes.

Let's say it's kind of an extra downloading slot for (if the user has set so) a couple of minutes, so, when that "almost finished" download actually finishes, the new download will have completed the "handshaking" protocol (if not called this way, it reminds me that one), probably obtained some small piece of bandwith and, most importantly, when that "almost finished" download actually finishes, it will be in position to kind of competing for it's piece of freed bandwith.

As you may also think, as soon as this happens, that extra downloading slot would disappear until next time needed.

I request this feature since it's something I've been manually doing for a long time and, as I see it, I think it does not harm the Currently Downloading items (it just gives them a little less of the freed bandwith) and improves the performance for the next new downloading item.

What do you think about it?

Thank you for taking your time to read me and the beautiful job of those who take part making the best p2p client. I actually use or recommend no other, period.

Tensk.

[Ultima]

Translation: When a torrent is almost complete, start the next torrent in the queue (early, so overall bandwidth usage doesn't need to go down for the short period of time needed for speeds to ramp up in the newly started torrent).

Personally, I don't really see why the extra bit of time makes much of a difference, but I'm not really in a position to disagree with this otherwise legitimate request. (On that note, I don't really see it being implemented, but again, not for me to decide)

Note: lol after having worked on some group and set theory today, I was ready to stop reading this thread from the beginning if only because I'm tired of indices xD

[Switeck]

In a nutshell, Download interleaving.

If you put the don't count slow downloads value high enough, uTorrent probably could already do this.

Also, you may be having this problem in the first place because of low upload speed max and/or bad uTorrent settings.

[Tensk]

Ultima, that's it, your translation is accurately right. It's not that makes much of a difference, it's more kind of a fine tuning. I mean that, doing things as they're done now, the items in the "still downloading list" have preference over new items. That's right if you want to see it that way. My "request" is heading to a "let's give the new item the bandwidth (or more precisely part of it) that the last one has freed", instead of making it directly compete for it (as they will inevitablely do later, but hey, they are always doing so) starting at nothing.

As kind of an aside effect (which is not so aside actually since it's the other reason I've come to think of this), the total bandwith of utorrent will be more constant. I mean, doing things as they are now, you can clearly see (well, this depends on many factors but, this usually happens this way) the downloading (even the uploading) graph to come down, and won't come up until some time after. Doing this way won't prevent that from happening but it will short the time to come up, so the effective bandwidth use is actually more constant... or that's what I think.

Switeck, I don't think of it as a problem rather than a fine tuning feature. I speak Spanish and Galician (English being my third language then, sorry for my mistakes then), so that may be the cause for me not to find the "don't count slow downloads" value in the options (maybe the translation is so different I can't see it). And really, I've tried with several settings and it will always do the same since, IMHO, I really do think it doesn't depend on settings but it is a natural behavior itself.

BTW, Ultima, I've studied computer science at college so... I'm used and familiar with indices, it's kind of a, hummm, fourth language to me? heh ;-)