Estimation
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.
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. One possible cause of this behavior is an estimation where the current transfer rate is given the most weight, 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 lights, traffic jams, or expressways. File transferring is 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".