Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix incorrect seconds_per_step calculation
seconds_per_step looks at a ring buffer with samples taken each tick. Each sample is <duration of the tick> / <number of progress steps> This results in an incorrect seconds_per_step, when this is calculated as a raw average of the buffer values. This is because we have no reason to assume any tick is a more representative sample than any other tick, but this will treat ticks with very few steps as *more* representative than steps with many ticks, because the value of the denominator is lost. The result is a very poor ETA / bitrate estimation when step production follows a burst-wait pattern, since ticks with few or no steps are to be expected. A better estimate could be achieved by averaging over the step-rate of each tick, but this would still not be ideal since it would treat short ticks as equally representative as long ticks in the average. Instead, we make two changes: First, we change the buffer to store the total number of steps rather than the difference between steps. This necessitates changing the new / reset code to set the first buffer item to zero. Second, we create a second ring buffer to store the timestamp of each tick. As a result, we can calculate the `seconds_per_step` rate by simply looking at the earliest values in the buffer, and returning `(now() - first_time) / (last_steps - first_steps)`. By using `now()` instead of `last_time` in the above equation, we also fix an additional issue. Since we only add items to the buffer when new steps occur, the progress bar freezes and the ETA does not update when progress stalls. By always using the latest time, we get a more accurate seconds_per_step estimate with no additional overhead.
- Loading branch information