Computing Library › Real Time Systems
Real Time Systems

Worst-Case Execution Time

WCET is the provable upper bound on how long a piece of code can take; every real-time timing proof rests on trustworthy WCET values.

Why the Worst Case

Real-time guarantees depend on the maximum time code can take, not the average. Worst-case execution time (WCET) is the largest possible execution duration of a task over all inputs and all hardware states. Schedulability analysis feeds on WCET: if the number is wrong, the timing proof is wrong.

Why It Is Hard

Kronos motion — confinement time

On modern processors the same instruction sequence can vary enormously in duration depending on cache state, branch prediction history, pipeline occupancy, and memory contention. A loop that runs in one microsecond with warm caches might take ten with cold caches. WCET analysis must account for the pessimistic combination of these, which is difficult on hardware designed to optimize the average case.

Approaches

The Pessimism Trade-Off

A sound WCET bound must never underestimate, so it errs high. Too much pessimism wastes capacity by reserving time that is never used; too little risks an unsafe bound. Making the hardware more predictable, by disabling speculation, locking caches, or using simpler cores, tightens the achievable bound because there is less variability to account for.

Practical Discipline

Robust WCET work avoids constructs whose duration depends on data in unbounded ways: no unbounded loops, no recursion without a proven depth limit, no dynamic memory on the critical path, and no blocking calls of unknown duration. Code is written to have a small, analyzable set of paths. The resulting bound is combined with blocking and interference terms in response-time analysis to prove the whole system meets its deadlines.