Computing estimated times of file copies / movements?

Question

Inspired by this xckd cartoon I wondered exactly what is the best mechanism to provide an estimate to the user of a file copy / movement?

The alt tag on xkcd reads as follows:

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.

Ignoring the funny, is that really how it's done in Windows? How about other OS? Is there a better way?

Answer 1

Have a look at my answer to a similar question (and the other answers there) on how the remaining time is estimated in Windows Explorer.

In my opinion, there is only one way to get good estimates:

• Calculate the exact number of bytes to be copied before you begin the copy process
• Recalculate you estimate regularly (every 1, 5 or 10 seconds, YMMV) based on the current transfer speed
• The current transfer speed can fluctuate heavily when you are copying on a network, so use an average, for example based on the amount of bytes transfered since your last estimate.

Note that the first point may require quite some work, if you are copying many files. That is probably why the guys from Microsoft decided to go without it. You need to decide yourself if the additional overhead created by that calculation is worth giving your user a better estimate.

Answer 2

I've done something similar to estimate when a queue will be empty, given that items are being dequeued faster than they are being enqueued. I used linear regression over the most recent N readings of (time,queue size).

This gives better results than a naive

(bytes_copied_so_far / elapsed_time) * bytes_left_to_copy