Everyone who has used Windows in this life has experienced it. When we copy, transfer or delete files on the system, a progress window always appears with the estimated time of the operation, and depending on the case, the prediction tends to be extremely erratic.
There are reasons for this, and now we can learn many of them thanks to one of the engineers responsible for creating and maintaining the Windows progress dialog: David Plummer. This is the same man who created the Windows Task Manager and left Microsoft many years ago. However, despite the time that has passed and the many other developers who have worked on this and other features of Windows, the predictions are still far from perfect and this is why.
2 minutes to go, now 2 hours to go…done in 30 seconds
Dave is just one of many people who have worked on the Windows progress dialog since the days of Windows 95, and he explains that he worked on it until around 2003. Interestingly, he The last thing that was dedicated to exactly was to improve the prediction of the time that an operation will take to complete when it involves many files.
In a video posted on his YouTube channel, where he often tells anecdotes and explains interesting things about computing and his experiences, Dave has asked that he be blamed for the fact that that progress bar does so bad.
The shell is trying to predict the future: The problem, as Plummer comments, is that the Windows shell’s prediction attempts to estimate the time remaining have to do only with what has just to happen or what is happening. This implies that the closer we are to the beginning of the process, the more wrong the prediction could be.
The creator of Windows Task Manager has published a great list of tips and tricks for using the tool
For example, if the operation involves a few small files, the shell probably estimates well that based on the time it took to copy the first of these, the rest will take approximately the same and make a more accurate calculation. Now, when the operation is more complex and involves multiple files of multiple sizes, the matter becomes very complicated.
“The only thing the dialog can do is assume that the future will be like the past, so base all of its predictions on this.”
How irrelevant it can be to know the size of the files and the speed of writing and reading of your disks: one would think that doing a simple calculation with the information you have about the size of the files to transfer + the speed at which your disks write and read data would be enough to make a good estimate, but one would be wrong.
The shell doesn’t know exactly, because it can’t know: Although the shell knows the total number of bits it has to copy, that’s only one factor in the result when predicting how much time the process will take. Most of the time it’s not that simple, and the shell can’t know exactly how much bandwidth will be free within the next minute. You don’t know how busy the disk will be, or the bus, or how saturated the SSD is, or if the cache needs to be rewritten, etc.
Things can change during the process: from changing network conditions, to multitasking applications slowing down I/O, to your disk slowing down as a large copy progresses, and stop counting. In this part David explains everything with an extremely practical example that I will try to replicate by changing a few things to adapt them to my audience.
Renfe trains still use Windows XP, a system from 20 years ago without support… but it’s not as terrible as it sounds
If Windows calculated the time it would take you to go from Valencia to Madrid
If you had to make a trip from Valencia to Madrid and the Windows dialog box was in charge of predicting the time it would take, the system would start estimating the time at the moment, for example, you start walking from your house to the Metro stop.
With that information, Windows would tell you that you arrive in three days, simply because you are walking at that time. Remember that you can only predict based on what has happened so far. Once you get on the subway that estimate would change back to a much shorter one given the extremely higher speed at which you are moving.
However, as soon as you get off the subway and walk to the train station, for example, the estimate will change back from hours or minutes, to days. Suddenly, when you go on the Renfe at 250 km/h, the prediction would put you there again in minutes, as if you were going from the train directly to the door of the hotel. This is because, again, Windows cannot predict that you will get off at the station and have to spend an hour in Madrid traffic to reach your final destination.
The Windows shell is not Google Maps: Unlike something like Google Maps which predicts with extreme accuracy the time it takes to go from one place to another by different routes, that dialog box Windows isn’t using a huge database of millions of other users who’ve made the same trip before to predict the most likely outcome. Windows just doesn’t work like that.