How does Windows Determine the Amount of Time it Takes to Perform an Action with a File?

By Akemi Iwaya on July 17th, 2014


The ‘time remaining’ estimations on Windows are enough to drive anyone crazy at times, but have you ever wondered how Windows determines those times? Today’s SuperUser Q&A post has some answers for a curious, yet frustrated, reader’s question.

Today’s Question & Answer session comes to us courtesy of SuperUser—a subdivision of Stack Exchange, a community-driven grouping of Q&A web sites.

Windows 8.1 file transfer window screenshot courtesy of im really famecore.

The Question

SuperUser reader ‘im really famecore’ wants to know how Windows determines the amount of time it will take to perform an operation with a file:

I wanted to know if there is an equation that Windows uses to determine how long it takes to perform an action with a file such as: deleting, copying, erasing, or installing.


For example, when I delete a file and Windows says Time remaining: 18 seconds, how is it calculating this number, and what does it use to calculate it?

Does Windows use a special equation to determine the time remaining to perform an operation, or does it just provide a ‘best guess’ estimate?

The Answer

SuperUser contributors Valmiky Arquissandas and Richard have the answer for us. First up, Valmiky Arquissandas:

Have you noticed that it usually does not give you any estimates during the first few seconds?

That is because during the first few seconds, it just does the operation it has to do. Then, after a short amount of time, it knows how much it has already copied/deleted/etc, and how long it took. That gives you the average speed of the operation.

Then, divide the remaining bytes by the speed, and you have the time it will take to complete the operation.

This is elementary school math. If you want to travel 360 km, and at the end of the first minute you have traveled 1 km, how long will it take you to reach your destination?

Well, the speed is 1 km/minute, so that is 60 km/hour. 360 km divided by 60 km/hour gives you an estimated time of 6 hours (or 360 km / 1 km/minute = 360 minutes = 6 hours). Since you have already traveled for one minute, then the estimated time left is 5 hours and 59 minutes.

Substitute travel with copy, km with bytes, and that answers your question.

Different systems have different ways of estimating time. You can take the last minute and the estimates may vary wildly. Or you can take the full time, and if the speed actually changes permanently, your estimates may be far removed from reality. What I described is the simplest method.

Followed by the answer from Richard:

If you are interested, this question tells you how Windows and OSX formats the time left into the progress bar once it has an idea how long it has remaining.

When shortening time expressions in progress dialogs, should they be rounded up or down?

Raymond Chen, a developer on the Windows team at Microsoft, confirms this algorithm (see Valmiky’s answer above) in a posting on his blog. He also explains why it can be wrong.

Why does the copy dialog give such horrible estimates?

Have something to add to the explanation? Sound off in the comments. Want to read more answers from other tech-savvy Stack Exchange users? Check out the full discussion thread here.

Akemi Iwaya is a devoted Mozilla Firefox user who enjoys working with multiple browsers and occasionally dabbling with Linux. She also loves reading fantasy and sci-fi stories as well as playing "old school" role-playing games. You can visit her on Twitter and .

  • Published 07/17/14
More Articles You Might Like

Enter Your Email Here to Get Access for Free:

Go check your email!