Why the estimate keeps jumping#

SLOP2805 · Week 5

“About 4 minutes remaining” is not a measurement. It is a prediction — and predictions have error. Today is not about removing that error. It is about what you are allowed to put on the screen once you know how big it is.

Where we were, and where we are going#

Week 3 gave you a denominator and a number for what it excludes.

This week turns that denominator into a time — and measures how much the time contradicts itself.

By 17:00 you can:

• compute a time-remaining estimate three ways from the same data
• measure an estimator’s instability as a number and compare estimators on it
• say what each one assumes about the future, and name the traffic that breaks it

The case#

trace-office-wifi.json — a real-shaped upload, recorded once and replayed identically for everybody in this room.

• 60 MB
• finished in 94 seconds
• fast for 40 s, then 12 seconds of almost nothing, then recovery

Everything today runs over this one file, so when your number differs from your neighbour’s, the estimator is the only thing that differs.

Simulated data. The trace is recorded sample data shipped with the course prototype, not a live capture taken during class. That is what makes it replayable, and replayable is the whole reason the exercise works.

What the user saw#

A naive estimate, refreshed every two seconds, across the stall:

Every one of those was correctly computed.

One equation, three readings of one word#

remaining work  ÷  rate

The work is settled — you chose a denominator in week 3.

So the entire design space is: what does “rate” mean?

1 · Naive linear#

rate = progress / elapsed

Assumes the future looks like the whole past.

• very stable while conditions hold
• early fast seconds keep propping the average up
• so it is wrong for a long time after things change — and wrong in the reassuring direction

2 · Sliding window#

rate = Δprogress over the last n seconds

Assumes the future looks like the recent past.

• reacts to the stall quickly — that is the point
• reacts to every ordinary fluctuation — that is the cost
• the window length is the whole design: too short is noise, too long is the naive estimator wearing a hat

3 · Exponentially weighted#

rate = α · sample + (1 − α) · rate

Assumes the future looks like the recent past, smoothly.

• one parameter, no buffer
• gentler response to a spike
• α is doing the same job the window length did, and is just as much of a design decision

None of them knows about the stall — and they should not#

An estimator turns a rate into a time.

Noticing that the process has stopped is a different job, from a different signal — the timestamp of the last progress event — and it belongs to week 8.

Two clean mechanisms beat one clever one. Keep them apart.

Worked example — instability, measured#

Same measure for all three, or you cannot compare them:

mean absolute change in the displayed value between consecutive refreshes, in seconds

Note what this does not measure: how close any of them got to 94 seconds.

It measures what the user experiences — how much the number jumps.

The counterexample#

Run the same three over trace-steady.json: 60 MB, no stall, even rate.

The ranking reverses. Sliding window and exponential smoothing now spend their reactivity on noise that means nothing, while naive linear — the estimator that failed so badly ten slides ago — is the calmest and the most accurate.

There is no best estimator. There is a best estimator for a traffic pattern, and you do not get to know the pattern in advance.

Discuss — 25 minutes#

A smooth estimate that is wrong for twenty seconds, or a correct estimate that visibly panics.

Which do you ship, and who does your answer disadvantage?

Consider: someone deciding whether to leave their desk. Someone on a metered connection. Someone who has already lost this file once.

Your turn — the build, and what leaves the room#

1. Three estimate() bodies over both traces — the trace and the plotting harness are supplied; you write only the function bodies
2. Six instability figures, one measure
3. A decision, printed on your interface: which estimator, rounded to what, refreshed how often

The mistake to expect: a rounding rule that reduces nothing. If the display changes as often as the underlying estimate, the rule is doing no work.

Where it goes: the named estimator is condition (b) of Assignment 2, and it is one of the first rows in the week 10 claims register.