612: Estimation

Explain xkcd: It's 'cause you're dumb.
(Redirected from 612)
Jump to: navigation, search
They could say "the connection is probably lost," but it's more fun to do naive time-averaging to give you hope that if you wait around for 1,163 hours, it will finally finish.
Title text: They could say "the connection is probably lost," but it's more fun to do naive time-averaging to give you hope that if you wait around for 1,163 hours, it will finally finish.


When moving or copying files using Windows Explorer, a dialog box opens to inform the user how long it would take. However, to the bafflement of many the time often keeps wildly fluctuating. This comic pokes fun at this quirk of Windows.

The reason why this happens is because Windows calculates the estimate purely based on the current transfer rate, which if we were to continue with the car scenario put forth by Randall, is like giving an ETA based on the speed the car is currently at with no consideration of the future, such as traffic lgihts, traffic jams, or expressways. Transferring files are limited by various factors such as how fast the files can be read, how quickly the disk can be written to, and even the size of each file themselves (think the difference between carrying a large box versus having to carry a hundred miscellaneous items).

A better implementation would keep track of the average file transfer rate over the entire operation, which would even out the bumps and give a more accurate estimate. Windows 8 avoids the problem by doing away with the time estimate.

The title text refers to the fact that if the connection is lost, and data can no longer be transmitted, the estimation just gets larger and larger as time goes on rather than realizing that no data being sent means there is no connection. This is a behavior that occurs on Microsoft network connections even when the connection is not lost. Kubuntu avoids this problem, but not that of wide fluctuations, by including only the past few seconds in its estimate. If there has been zero progress within the averaging interval, it reports "Stalled".


In 2021, Dave Plummer, whose team worked on the Windows progress dialog, created a video in response to this strip. It further explains why the estimate can be wrong and fluctuate extremely.


[Cueball is in a car, talking on his phone.]
Cueball: I'm just outside town, so I should be there in fifteen minutes.
Cueball: Actually, it's looking more like six days.
Cueball: No, wait, thirty seconds.
[Caption below the frame:]
The author of the Windows file copy dialog visits some friends.

comment.png add a comment! ⋅ comment.png add a topic (use sparingly)! ⋅ Icons-mini-action refresh blue.gif refresh comments!


I've experienced this more strongly while installing programs rather than transferring files, and the "connection lost" part is not exclusively from Microsoft. 22:06, 3 January 2014 (UTC)

I think there needs to be some explanation on what "per-file overhead" is, for those who don't know - myself, for instance. Codefreak5 (talk) 22:12, 17 July 2014 (UTC)

It's the time spent looking up the destination folder, adding an entry for the file in that folder (a folder is an index of file names and locations, not a physical division of the disk), and recording metadata such as the creation date and owner. Basically, it's the time it would take to move the file to a different folder on the same disk, minus the time it would take to delete the file (bypassing the Recycle Bin). Promethean (talk) 06:08, 18 July 2014 (UTC)

In fairness, I wonder if we should mention that this is a really hard problem to solve. it's only a little bit easier than the extremely hard problem given in 1425: Tasks. User: 00N8 (talk) 00:02, 5 March 2018‎ (UTC)