Measuring ETA

[cruci]

I'd like to have the option to see ETA in terms of average speed over a period of time (last five minutes, last ten minutes etc) rather than getting a wildly erratic ETA based on the current speed the torrent happens to be downloading at.

[cruci]

This is looking all kinds of lonely. Could it be done? Is it a worthwhile feature?

[bleh]

Well, you can't really get a "stable" ETA with an unstable network like BT.

What you can do to get a less jumpy eta, is to set your GUI to update less frequently.

(perhaps some bigger values for the GUI update algorithm would be nicer?)

[chaosblade]

Nah, more then 10s is really pushing it ;]

[infidel]

I'd like to have the option to see ETA in terms of average speed over a period of time (last five minutes, last ten minutes etc) rather than getting a wildly erratic ETA based on the current speed the torrent happens to be downloading at.

I also would like to see this feature, and it would not be hard to calculate to keep it a bit more stable. It would of course always update and change as the download progresses, but it would keep it from going from 1h 21m to 9h 15m in one tick if a seed or fast peer drops out. The cycling is just too fast. Setting the screen update speed lower as some people suggested wouldn't make any difference, as the data provided itself is only valid for that particular window of time and therefore it isn't useful for rendering a true estimate. If you took the data points from one download and plotted the ETA on a graph, it would make more sense.

Something like the below code should provide a somewhat more smooth estimate, yet still updated over time to indicate fast seeds that join later, drop out, etc. You could even have a feature to reset the ETA loopcounter and totalbps aggregate values to 0, which would reset the ETA calculation from scratch mid-download if the user desires.

// A simplified example
long totalbytes = 1234567890, loopcounter = 0;
float totalbps = 0;
while (updateloop) {
    long currbytes, etasecs;
    float currbps, avgbps;

    avgbps = (totalbps += currbps) / ++loopcounter;
    etasecs = avgbps / (totalbytes - currbytes);
}

Other than this, uTorrent is GREAT! The only reason this is a sticking point for me is because it doesn't really do what it is designed to do: let the user know any useful information as to roughly how long the download will take.

Thanks bunches for uTorrent.

-Infi

[ifmusic]

now That's An Post infidel.

[Anno]

I concur, this actually isn't a feature, but the way it currently it is clearly a bug.

[ICleolion]

Ludde has no plans to change how his client measures ETA. Apparently it already averages it out. Which is why i deleted my thread.

[Firon]

yeah, it already does according to him

[Nefarious]

well, it does, but not acurate enought i've seen change from 1w 1d to 2w 3d on just one update from the GUI, and then comming back to 1w 2d or so

[Anno]

Exactly, if it averages it out, then the time interval currently is far too small to actually give any worthwile result.

[Firon]

changed for the next beta

[Anno]

Cool, thank you!

[Nefarious]

thanks, thanx all

[TheDude]

changed for the next beta

It's not in the next three betas after you posted.

Which beta did you mean ?

As mentioned in a closed thread on the same topic (which was started because the Forum Search feature doesn't work very well), the ETA used by BitTornado (and thus ABC as well) works really well, and gives one a stable ETA that is very accurate, and hardly changes at all.

Since that is open source, there is no reason that the developer of utorrent could not look at that code to see how it works.

Currently, in order to get a more accurate ETA, I have to subtract the start time from the time of day and divide by the percentage completed. If I can get a more accurate ETA in 10 seconds using a $3 calculator...