Estimation Skills

[andrewducker]

I get annoyed by download information that makes utterly useless stabs at how long something is going to take to finish.

For instance, I am currently 9Gig through a 24Gig download (Dragon Age: Origins) and this has taken 254 minutes. I would therefore seem to be taking 24 minutes per Gigabyte (590kB/s), and it will thus take me a total of 677 minutes. So, 7 hours and 3 minutes to go.

However, because my current download speed is about 1MB/s, it's telling me that my remaining time is about 250 minutes (4 hours and ten minutes). Now, while it's _possible_ that I'm going to get lots more stable bandwidth than I did in the first half, it seems unlikely. And the fact that it has a lot of data about how much I get to download over a long period and _isn't_ using that to calculate my remaining time drives me nuts.

I would have thought that a reasonable formula would be to balance off the current speed against the average speed so far - with current speed being more important the closer we get to the end, and average speed being more useful when we're further away from the end (and thus having to deal with more variance during the time remaining).

A nice simple formula for that would be:
Speed estimate = (Average speed*percentage done)+(Current speed*percentage remaining)

Which gives me 296 minutes - about five hours.

This would iron out the bumps in the estimation process (sharp swings in download speed wouldn't yank the estimates up and down quite so much), and hopefully give a more accurate figure. Of course, recalculating based on the average download speed in the last 1% of the download, rather than the last 5 seconds (which seems to be what Steam is doing) would be a lot more useful too.

Sadly, no matter which one of the figures is right here I'm going to be asleep when the download finishes, so I'm never going to know. Still, at least playing with numbers has kept me distracted for a bit...

Comments

[dougs.livejournal.com]

I think http://xkcd.com/612/ is appropriate here.

[andrewducker]

Exactly!

I don't mind estimates varying during something happening - but the sheer amount it varies is silly, we should be able to deal with it better than that. Averaging over a percentage of the operation time, rather than the last couple of seconds, and taking into account long-term averages both seem so obvious I can only assume that the people who write these things have better things to spend their time on.

Being a developer myself I know that stuff like that would only get written if someone working on the code got fed up with it themselves and decided to write a better estimator, and then snuck the code in when nobody was looking.

[andrewhickey.livejournal.com]

We have a product which says "this may take several minutes" to install. That's true on SuSE. On RedHat, it can be *six hours*. None of the dev/test team approve of this statement, but it's still there...

[andrewducker]

I'd like to know what the %^&%^& takes a factor of 60 times longer on one version of Linux than another...

[andrewhickey.livejournal.com]

Will email you details, as it would identify the program, which would link my work and net life more than I like...

[ciphergoth.livejournal.com]

TBH I suspect the most reliable estimate wouldn't have any recency bias at all, it would just estimate based on average speed.

[drdoug.livejournal.com]

A simple arithmetical mean might be misleading, though, particularly if your throughput is highly variable - a geometrical mean ought to be more accurate. And - particularly at the start of a long download - it'd be prone to the sort of wild jumping around that XKCD cartoon is sending up, unless you have some clever damping.

Some recency bias might make some sense, though - with this particular download, my bet would be that it finished closer to the 4h10m than the 5h estimate, and certainly less than 7h3m, because the tubes will be emptier late at night than they were over the course of the download up to the time of the OP, which spanned the UK peak net congestion time. (My fatalistic estimate is that it crashed out, or paused for some user intervention, shortly after andrewducker went to bed.)

I reckon that this is one of those problems, like search, where Wrong answers are obvious to most people, but getting it Right is a lot harder than most people think.

The thing that seems obviously Wrong to me about all of the download/completion time estimates I've ever seen is that they are a single figure, with no range indication, and frequently with hopelessly spurious precision. Nonsense like '8 hours 23 minutes 46 seconds remaining' is far from unusual.

[ciphergoth.livejournal.com]

We need data!

Steam should be collecting the data they need to get this right, they're in an excellent position to do so.