Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#3648 closed Enhancement (wontfix)

Provide an estimated time to completion based on the average speed

Reported by: dskchk Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.11
Severity: Major Keywords:
Cc: noone3@…


The current ETA is calculated using the current download/upload speed (more precisely: it uses an average speed from over the last few time slices, but this period is very small). This means that, since the current speed changes rapidly, the calculated ETA, if available, is almost useless, because it changes at every refresh of the data sent by Transmission daemon.

Given that:

  • my actual Internet bandwith is always the same (on average)
  • except for fresh new torrents, it's unlikely that the availability of peers changes a lot within the download time of a file, especially for rare files

I think that using the average speed would permit to calculate a much more reliable and stable (over time) ETA like this:
ETA (average) = (total download time * remaining size) / downloaded size
The total download time is the Transmission uptime since the last resume of the torrent.
Once Ticket #1408 has been done, this could be easily added.
The new ETA might not replace the existing one, but be an added information.

Real world example:
I have a file which is seeding. This is what I see:
at t1, current speed 9 KB/s, ETA 4d 10h
after 5 seconds: 7 KB/s, 4d 10h
after 5 seconds: 6 KB/s, 6d 15h
after 5 seconds: 9 KB/s, 4d 10h
after 5 seconds: 7 KB/s, 5d 16h
after 5 seconds: 9 KB/s, 4d 10h
after 5 seconds: 8 KB/s, 4d 23h
and so on...
So, the ETA varies of even 2 days (!!!) within 30 seconds and changes almost at each refresh. In this example the speed variation is low (2 KB/s at most, since I'm uploading), but while downloading the situation is much worse, since the download speed can quickly vary from 0 KB/s to at most 120 KB/s on my ADSL line, depending on the peers. This makes the current ETA totally useless.

Another example: I'm downloading a 3,48 GB file and I'm at 90,3%. This download is very slow and it took about three weeks to get to this state. Transmission is currently saying it will be completed within 5h 45m, 13h 56m, 1d 9h, 4d 2h, 1d 0h, 8h 52m and so on (I'm reporting the speeds at each refresh, period 5 seconds). So I can't really understand how much it will take to finish. Anyway, if I consider the average speed (with the formula above) I expect it to finish within about a couple of days. I'm sure it will go that way (or much likely).

Change History (6)

comment:1 Changed 11 years ago by dskchk

  • Cc noone3@… added

comment:2 Changed 11 years ago by livings124

Having an eta based on available speeds from days, weeks, or months ago seems like a bad idea to me. And having multiple eta options will not be added.

comment:3 Changed 11 years ago by livings124

  • Resolution set to wontfix
  • Status changed from new to closed

comment:4 Changed 11 years ago by dskchk

You don't explain why this seems like a bad idea to you. What is wrong with my use-case description? Do you really think that my every-day experience with Transmission is a "bad idea"? Do you really find the current ETA useful to have a realistic estimate to completion?

comment:5 Changed 11 years ago by livings124

I believe I did explain. An estimate based on historic speeds isn't useful, especially the further you go back. That doesn't take into account if the user changes networks or anything like that. And having two eta's is more confusing for most users - it's bloat that will be useful to you and near-no none else.

comment:6 Changed 11 years ago by dskchk

So, is it more likely that you change network (!?) while you are downloading a file rather than having a constant bandwidth for whole the time? I don't know what are the Internet connections in your country, but in mine most people have ADSL lines and it's very unlikely that one would "change network" from one day to another. Moreover, I really can't understand why it sounds so bad to use the history to calculate an ETA given the fact that if it took to me 5 days to download 1 GB, it's quite reasonable that it would take another two days to download the remaining 400 MB of the same file, rather than reporting totally different numbers every five seconds...

Just for my curiosity, how do you (in your real download experience) currently know what is a reasonable remaining time to complete downloading a file? Do you really rely upon what Transmission says? Right now the ETA calculated by Transmission is actually a random value, since it depends on the actual speed of the download (which is like to be a "random" result of the current network/peer status). I don't know how a random value can be more useful than something calculated through a sort of retroactive system (=> the downloading history).

More, this useless feature, as you say, is already implemented by other P2P software...

Last edited 11 years ago by dskchk (previous) (diff)
Note: See TracTickets for help on using tickets.