Why does Windows Progress Bar always give such horrible estimates? [duplicate]

Question

Possible Duplicate:
Windows File Copy Dialog: Why is the Estimation So… BAD?

I realized this "bug" a long time ago, since Windows 95/98, but it still continues until today, on Windows Seven.

Today I was compressing a 1GB folder with the Windows zip(it is not a exclusive event from compression process, I already seen this before on a copy/paste of files), as shown above:

(It is in Portuguese, but is the screen for the Windows progress bar showing 60 minutes of remainder time to complete the compression process)

The displayed remainder time was on 60 minutes, but the real time was less than 2 minutes.

There is any specific reason to this strange event happened? There is some way to refine or correct this kind of "bug"?

Answer 1

Raymond Chen wrote a very nice article about this once. Basically, the dialog is just guessing :).

http://blogs.msdn.com/b/oldnewthing/archive/2004/01/06/47937.aspx

"Because the copy dialog is just guessing. It can't predict the future, but it is forced to try. And at the very beginning of the copy, when there is very little history to go by, the prediction can be really bad.

Here's an analogy: Suppose somebody tells you, "I am going to count to 100, and you need to give continuous estimates as to when I will be done." They start out, "one, two, three...". You notice they are going at about one number per second, so you estimate 100 seconds. Uh-oh, now they're slowing down. "Four... ... ... five... ... ..." Now you have to change your estimate to maybe 200 seconds. Now they speed up: "six-seven-eight-nine" You have to update your estimate again.

Now somebody who is listening only to your estimates and not the the person counting thinks you are off your rocker. Your estimate went from 100 seconds to 200 seconds to 50 seconds; what's your problem? Why can't you give a good estimate?

File copying is the same thing. The shell knows how many files and how many bytes are going to be copied, but it doesn't know know how fast the hard drive or network or internet is going to be, so it just has to guess. If the copy throughput changes, the estimate needs to change to take the new transfer rate into account."

Answer 2

The only way to know how long it'll take to compress a set of files is to compress them. Sometimes Windows' best guess is close, sometimes it's wildly wrong. The same is true of copying large numbers of files, as I'm sure you've noticed.

It's not so much a bug as a useless display of seldom-accurate information. The best way to fix it is to close your eyes. Ignore it. ;-)

Perhaps there's a program out there that can copy/compress files and make an alarm sound when it finishes. That would be truly useful. We could have a little nap while we wait for Windows to finish the housecleaning.

Answer 3

I think the reason was nicely explained in one of the comments of the blog post linked by Roald's answer:

It has a horrible estimate algorithm. There are no excuses. If has to copy 1000 1KB files and 10 1MB files it thinks it will be as busy with the 1 MB file as with the 1KB files.

The reason it gives such horrible estimates is that it's not well done. Obviously it can never be 100% precise but it could be much, much better.

Answer 4

There is some way to refine or correct this kind of "bug"?

As Roald van Doorn said, it's basically just guessing. Of course, that does not mean it couldn't be a better guesser. There are plenty of heuristics that could be used to calculate this.

1. The best way, most expensive way, would be to keep a history of previous 'copies' and then use artificial intelligence algorithms to calculate a guess
2. One could construct a formula based on research of how long it should take. They could take in account things like: file system, number of files, size of files, disk seek time, disk bulk read/write speeds, location of files on disk (fragmentation), current disk utilization.
3. A mix of the two. Ie. do some benchmarks to find out how long certain operations take and then use those as a history for simple formulas.

Obviously none of this is easily implemented.. and I only mentioned file copies. Similar work would need to be done for all sorts of transfers.
The question you have to ask yourself- Would you rather microsoft spend it's time giving you a better estimate or would you rather they make your files transfer faster.

However, If you compress something with 7-zip, you'll notice it's much better as guessing than windows is. I doubt it's doing something that complicated, just a slightly better guesser.

Answer 5

There is some interesting answers on the msdn blog about this. As to why it is hard:

Estimating the time remaining to complete a copy is nearly impossible to do with any precision because there are many unpredictable and uncontrollable variables involved – for instance, how much network bandwidth will be available for the length of the copy job? Will your anti-virus software spin up and start scanning files? Will another application need to access the hard drive? Will the user start another copy job?

And how they are improving,

Rather than invest a lot of time coming up with a low confidence estimate that would be only slightly improved over the current one, we focused on presenting the information we were confident about in a useful and compelling way. This makes the most reliable information we have available to you so you can make more informed decisions.

That said, if you really want to improve just the given estimate and keep the progress bar as it is, you could do something suggested on the slashdot comment:

Maintain a table of expected speeds for each storage device on the filesystem. Record how long it takes to read the filesystem information. When a device is mounted, if it's reasonable for the device type, seek to the middle and end, measuring speeds there, too. Get approximate curves for the read and write speeds across locations, and use those for future estimates. For future read and write operations, take note of where they are and how fast they go, and adjust the curves accordingly.

When an operation starts, look at the curves for input and output for the respective devices. Find the expected speed for the target location. Whichever speed is lower should be used for the estimate.