Norms, rules or guidelines for calculating and displaying "ETA / ETC" for a process

Question

ETC = "Estimated Completion Time"

I calculate the time taken to complete the cycle and show the user some numbers that tell him how much time the whole process will take. I feel that this is a common thing that everyone does sometimes, and I would like to know if you have any recommendations that you follow.

Here is an example that I am currently using:

int itemsLeft; //This holds the number of items to run through. double timeLeft; TimeSpan TsTimeLeft; list<double> avrage; double milliseconds; //This holds the time each loop takes to complete, reset every loop. //The background worker calls this event once for each item. The total number //of items are in the hundreds for this particular application and every loop takes //roughly one second. private void backgroundWorker1_ProgressChanged(object sender, ProgressChangedEventArgs e) { //An item has been completed! itemsLeft--; avrage.Add(milliseconds); //Get an avgrage time per item and multiply it with items left. timeLeft = avrage.Sum() / avrage.Count * itemsLeft; TsTimeLeft = TimeSpan.FromSeconds(timeLeft); this.Text = String.Format("ETC: {0}:{1:D2}:{2:D2} ({3:N2}s/file)", TsTimeLeft.Hours, TsTimeLeft.Minutes, TsTimeLeft.Seconds, avrage.Sum() / avrage.Count); //Only using the last 20-30 logs in the calculation to prevent an unnecessarily long List<>. if (avrage.Count > 30) avrage.RemoveRange(0, 10); milliseconds = 0; } //this.profiler.Interval = 10; private void profiler_Tick(object sender, EventArgs e) { milliseconds += 0.01; } 

As a programmer at the very beginning of my career, I am curious to see what you will do in this situation. My main problem is that I am calculating and updating the user interface for each cycle, is this a bad practice?

Is there anything to do / not do when it comes to such evaluations? Are there any preferred methods for their implementation, for example. update every second, update every ten logs, calculate and update the user interface separately? Also when ETA / ETC would be a good / bad idea.

Answer 1

The real problem with estimating the time taken by the process is quantifying the workload . Once you can quantify this, you can make a more accurate assessment.

Good Grade Examples

• I / O file system or network transfer. Regardless of whether file systems have poor performance, you can find out in advance, you can quantify the total number of bytes processed and measure the speed. Once you have it, and as soon as you can control how many bytes you transferred, you get a good grade. Random factors may affect your assessment (i.e. the application starts in the meantime), but you still get a meaningful value

• High Stream Encryption. For reasons above. Even if you calculate the MD5 hash, you always know how many blocks were processed, how many should be processed and the total.

• Product synchronization. This is a little trickier. If you can assume that the workload per unit unit is constant or you can make a good estimate of the time required to process the element when the variance is low or insignificant, then you can make another good estimate to process. Choose email synchronization: if you don’t know the byte size of the messages (otherwise you get into case 1), but the usual practice says that most letters are the same size, then you can use the average time taken to upload / download everything Processed emails to evaluate the time taken to process one email. This will not work in 100% of cases, but error prone but you still see a progress bar on a large account

In general, the rule is that you can make a good assessment of ETC / ETA (ETA is actually the date and time the operation was completed) if you have a homogeneous process that you know numbers about . Homogeneity ensures that the processing time of a work item is comparable to others, i.e. The time taken to process the previous item can be used to assess the future. Numbers are used for correct calculations.

Examples of bad grades

• Operations on multiple files of unknown size. This time you only know how many files you want to process (for example, for downloading), but you don’t know their size in advance. Once the file size is highly dispersed, you see problems. Having downloaded half the file, when they were the smallest and summed up to 10% of the total number of bytes, can we say that they are halfway? No! You just see that the progress indicator is growing rapidly to 50%, and then much slower.

• Heterogeneous processes. For instance. Windows As @HansPassant noted, Windows installations provide worse than poor ratings. Installing Windows software involves several processes, including: a copy of the file (this can be evaluated), registry changes (usually never evaluated), and transactional code execution. The real problem is the last. The transactional processes associated with executing custom installer code are discussed below.

• Execution of common code. This one can never be appreciated . The code snippet includes conditional statements. Their implementation includes changing paths depending on the state external to the code. This means, for example, that the program behaves differently, regardless of whether the printer is installed or not, whether you have a local or domain account, etc.

conclusions

Estimating the duration of a program process is not an impossible and exact / * deterministic * task.

• This is impossible, because even in the case of code fragments, you can either find a model for your code (for example, choose LU factorization, this can be estimated). Or you can redesign the code that divides it into an evaluation phase — where you first define the branching conditions — and a run phase where all the predefined branches are accepted. I said, perhaps, because this task is almost impossible: most codes define branches as effects of the previous conditions, which means that evaluating the branch actually involves running the code. Chicken and Egg Circle

• This is not a deterministic process. Computer systems, especially if multitasking is dependent on a number of random factors that may affect your assessment process. You will never get the right grade before starting your process. At best, you can detect external factors and overestimate your process. fork between your estimate and the actual duration of the process mathematically converges to zero when you approach the end of the process (lim [x-> N] | est (N) - real (N) | == 0, where N is the duration of the process)

Answer 2

If your user interface is so obscure that you must explain that ETC does not mean Etcetera, then you are doing it wrong. Each user understands what the progress bar does, does not help.

Nothing is more annoying than an inaccurate progress bar. Especially those that promise quick completion, but then do not deliver. I would give a progress bar displayed by any installer on Windows as a good example of what is fundamentally broken. It’s just not a clear example of an implementation that you should pursue.

Such an indicator of progress is broken, because it is completely impossible to guess how long it will take to install the program. File systems are very unpredictable. This is a very common issue with estimating runtime. The best user interface models are the rotating dots that you see in the video player and in many programs on Windows 8. Or the highlighting style supported by the general ProgressBar control. Just feedback that says, "I'm not dead, working on it." Even a watch glass cursor is better than a poor score. If you have something to report that the technical user is not interested, then feel free to display it. As the number of processed files or the number of kilobytes downloaded. The actual value of the number is not so useful, because the speed with which it increases is an interesting tidbit.