During a profile run, the "estimated time left" indicator displayed may be very different to the actual time taken for the profile to complete. This is because the calculation to estimate the transfer time depends on several factors:
- The number/size of files being copied - Calculating the duration estimate to back up a few large-sized files would be far easier as opposed to copying thousands of small-sized files. This is because the system needs to create each file, move the Safe Copy (if enabled), set the file attributes, etc for each file copy process. Each of these "mini" processes needs to be completed in sequence before processing the next file and so on. This adds a tiny fraction of time delay with each start-stop process, which will skew the total time estimate when this is multiplied by the number of files to process.
- If the profile is backing up from/to a non-standard resource like FTP servers, Cloud services, etc, the duration may get affected due to the fluctuations of the Internet bandwidth, your ISP, the remote server load at the time, the routing, the number of files, etc are contributing factors to how fast/slow the process will take.
- With Compression turned on in a profile, it will get much worse, because there is no way for the program to determine how long each compression process for a given file will take. All of these is entirely dependent on its contents and how compressible it is, etc.
Even duration estimates calculated on the operating system level during a file copy process can be very bad, as discussed in this forum link example:
There is also a YouTube video from an ex-Microsoft employee explaining why it is so difficult to estimate the time it will take to copy files:
In summary, we will continue to try and improve the time estimates, but it will never be accurate.