Remaining-time estimates extrapolate recent rate; a rate shock makes them jump

What it is

“1 minute 20 seconds left” is almost never a prophecy. It is the leftover work divided by a speed taken from the recent past. Completed over elapsed gives a rate; remaining over that rate gives a number. If the speed changes in the next second — the network downshifts, the disk starts to stutter, the server queues — the same formula emits a very different number. The jump is in the method: extrapolation assumes a steady rate, and load rates often are not.

Why it happens

Extrapolation is a straight line: the past slope extended to the finish. A short window’s slope is noisy; instantaneous rate twitches and the finish swings. A long window’s slope is calmer but slow to a just-happened shift, and keeps reporting the old world’s remainder after the downshift. Neither is “miscalculation”; the stationarity assumption was punched through by physics: cellular after Wi-Fi, a worse compression ratio, the other side moving from flash to a spinning disk, a rate limiter engaging. Remaining time is a division by rate; as rate nears zero the number explodes toward infinity, then falls back to tens of seconds when rate returns. It looks like the system lying. It is the divisor jumping.

There is also a structure problem: work is not homogeneous. The first 80% is transfer, the last 20% decompress or verify. Extrapolating the verify segment from the transfer rate makes the finish suddenly farther when verify starts. The wrong segment was used.

Where it stops holding

On a truly steady pipe (a local bus, a negotiated constant bandwidth) extrapolation can be quiet; do not refuse a number just because jumps are possible somewhere. The first second or two has too little sample; there is no history, and this stretch should not emit a precise remainder — wait until the window holds enough completed work. When the user pauses or switches network, the rate shock is human-caused and the jump reflects the new pipe, not an algorithm fit — but it should still change smoothly, not from 8 seconds to 8 minutes in one frame. Monotonic progress forbids the bar from running backwards; remaining time will grow when rate drops. Growing remainder is not shrinking completed work. Do not use the no-regression rule to forbid a longer ETA, or the only option is to lie that it is still 8 seconds.

Applying it

• Compute rate from a smoothed window of completed-over-time (for example an exponential moving average). Do not divide leftover by last second’s instantaneous bytes.
• When rate falls through a threshold, do not let remainder explode into “999 hours”. Report a stage or switch to a range until the window restabilises.
• Extrapolate by segment: transfer rate on the transfer segment, processing history once processing starts. Do not use the wrong segment.
• How to check: at 40%, cut bandwidth to a tenth, then restore. If remaining jumps in a second or two from minutes to hours and back to seconds, instantaneous extrapolation was not smoothed. Log the jump size as acceptance for the window parameter, not as a copy issue.

Related

• Same group: I2.10.2 A range reflects uncertainty more honestly than a single precise number · I2.10.3 Revise the estimate as progress continues; do not freeze the first figure · I2.10.4 With no sound basis, show elapsed time rather than invent remaining
• Nearby: I2.02 Predictable progress · E6.09 Determinate and indeterminate progress · I1.05 Latency jitter
• Search terms: rate extrapolation · ETA jump · moving-average remaining time