# Improved ETA

## Recommended Posts

The current ETA column is next to useless (well, to me anyway) due to the constantly shifting value according to the transmission speed of the moment. I would like to see it instead calculated based upon the time it has taken to get the percentage acquired thus far, i.e.:

ETA = (M/C)*R

M = Total minutes (from "Time Elapsed")

C = Percentage complete

R = Percentage remaining

I feel this would give a much more accurate impression of the time remaining than the current method (my method, of course, presumes nothing significant will change in the way the DL has been progressing so far, but it's obvious that such things as peers disappearing are impossible to predict). Obviously this would not be much less variable than the current method when the DL first starts and/or on small DLs, but on the larger DLs (where ETA is more likely to matter anyway) it should be noticably more precise (and certainly more useful than the "infinite loop" character being displayed when no data is currently being received). If you like, perhaps my suggested method could be displayed in parentheses after the currently used ETA method (or make it an option as to which method is used).

Example: my current DLing torrent has a "Time Elapsed" (from the "General" tab) of "1d, 12h" and it is 37.4% complete, thus it works out to roughly "2d, 12h" remaining with my calculation ("M" = "1d, 12h" = 36h = 2160, C=37.4, and R = 100%-C = 62.6 thus making the calculation (2160/37.4)*62.6 = 3615.4m = 60.26h = 2d, 12h, 15m. (Sorry all if this explanation is overdone - I just wanted to make sure I was understood.)

Thanks again.

-Ape

##### Share on other sites

Hm, interesting suggestion... seems like it might work fairly well in making the ETA change a lot less often.

##### Share on other sites

nah, that would be useless if for example u were downloading 3 torrents each with 20kB/s, but then u stop 2 of them making the last one go 60kB/s but yet saying it will last 3 times longer that u have currently, it is fine the way it is now as speed changes all the time on most of the torrents, and never really stable to say u will take certain time based and what u got already, it changes acording to what ur average speed has been for the last few seconds which is perfect for changing speeds

##### Share on other sites

But with the suggested change, it wouldn't jump around as much, and that's what a lot of people complain about.

##### Share on other sites

i would start complaining that it doesnt changes with immediate changes, like switching from 10kB/s limited to unlimited download saying the same ETA even after i changed it 10 minutes ago, and i bet lot of people would start complaining about it as well

##### Share on other sites

No, the changes won't be immediate, but the ETA would start moving in the right direction. For example, if you downloaded 10% of a torrent in 5 minutes, and in the next minute, you manage to download another 10%, the ETA goes from 45 minutes to 24 minutes, which clearly reflects the change in speed.

##### Share on other sites

Yes, I thought of that was well - that's why I suggested it appear in parentheses after the current method and/or leave it up to the user which method is displayed. If you really want to be precise, then another alternative might be to keep a short history of each torrent - say the last 2-5 minutes or how long it took to get the most recent 1% - and base the ETA on that. Personally, while I think that it would be nice to have that option as well, I'm not that particular. It may be more effort to program than it's worth (never mind the question of memory efficiency), but that'll be up to Ludde & co. to decide if they choose to implement this suggestion.

Remember that it is called ESTIMATED Time of Arrival for a reason, however. I would think anyone who has just made changes that affect the speed of their active torrents would understand that the ETA calc would be affected by this and be able to mentally adjust for it somewhat until it "caught up." While it would be great to have the ETA adjust in an agile manner to changes in speed (the way it works now is TOO agile), I still want it to give a relatively more accurate (READ: "useful") measurement than it currently does.

Whatever the µT team thinks is worthwhile. It was just a suggestion/request.

##### Share on other sites

I would suggest calculating the ETA using the average connection speed of the last (for example 10) few minutes!

This wouldn't lead to the value jumping around, and if you disable the download limit, after 10min the value would be correct!

##### Share on other sites

This proposed method does (in essence) take the average speed to calculate the ETA. It's basically looking at how much time it's taken you to get as far as you have, and applies that to the ETA.

##### Share on other sites

Yes, Ultima, but Nefarious does have a point that I agree with (to a point - I still want something changed to make the ETA more accurate rather than just leaving it as it is). I can certainly see wanting to have more immediate feedback on what effect any changes you make to the active torrents might have - using the entire time the torrent has been active would not be terribly conducive to this. As such, using the speed over the past x minutes or time taken for the most recent y percentage points might make more sense.

Of course, you could really be anally thorough (as I would probably do ) and display all methods...

##### Share on other sites

Using the average speed on the last 5-10minutes seems fair to me, but not the whole download progress, thats a killer on big big really big torrents

##### Share on other sites

Another way to present it is to calculate all valid methods and either:

1. Display the lowest and highest results as a range, or

2. Display the mean of the results.

My schooling's long behind me, so I don't remember the statistics stuff. Whatever works best...

##### Share on other sites

• 2 weeks later...

[usless quoting removed by moderator]

Really?!? The way the figure it displays jumps about so wildly, I cannot imagine that it would average more than a few seconds at best. Would you mind detailing just exactly how it currently works? As I said initially above, I find it of very little use at the moment so maybe I'm just missing something...

##### Share on other sites

• 1 year later...

Yes, averaging the ETA over the past few minutes would be better than averaging it over a few seconds.

The BEST case would be if the preferences allowed changing the ETA option between:

current speed/1 minute / 5 minutes / 1% / 5% / completed so far.

The numbers here, of course, are my choice - the developers would probably know better.

##### Share on other sites

The ETA decays 16% per second. The d/l rate decays 67% per second.

#### Archived

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

×