Two tasks. One number. Most implementations get it wrong.

task A   100 µs every  400 µs   ← higher priority
task B   200 µs every 1000 µs

What is B's worst-case response time?

The obvious answer is 400 µs — two activations of A fit inside B's 1000 µs period, so 200 + 2×100. It is wrong.

The correct answer is 300 µs. The window that counts is the response time, not the period: at R = 200 one activation fits, giving 300; at R = 300 still one, so 300 is the fixed point.

Here the mistake is conservative and the system merely looks worse than it is. Change the periods and it inverts — the wrong method reports a deadline met that is missed on hardware. Both answers are plausible, neither is flagged, and a test written by whoever wrote the bug passes.

Check it in thirty seconds:

git clone https://github.com/DYResearch/dy-wcet && cd dy-wcet && cargo test

The case above is a_lower_priority_task_pays_for_every_preemption, one of forty-nine.

Real-time systems are full of numbers that nobody can reproduce. A worst-case bound computed in floating point differs in its last bits between compilers. An analysis that caps its iteration returns a number that looks like an answer. A sum that wraps turns a system that misses deadlines into one that appears to meet them.

None of these fail loudly. All of them fail in the direction that flatters the result.

The work here is narrower than a platform and more specific than a library: the pieces of real-time analysis where the arithmetic decides the answer, written so that the arithmetic can be checked.

The AxonOS kernel carries its own response-time analysis, written months earlier for a different reason. The two agree on a shared task set — and the first attempt at that comparison is the part worth reading.

It used a set whose execution times summed to less than the shortest period, so no task activated twice inside any response window. Every ceiling was 1, the fixed point was the first value tried, and what had been verified was addition. The set now used takes three iterations on its lowest-priority task.

The derivation, iteration by iteration →

Both implementations are by the same author, so this is not independent verification. A shared misreading of the recurrence would agree with itself perfectly, which is why every figure there is derived rather than asserted.

Integers, everywhere the result matters. Same input, same bits, any machine. A property a floating-point implementation cannot offer and a test cannot pin.

Refusal over approximation. When a computation has no answer, it returns that — not the last value before the loop gave up. An infinite response time fails every deadline comparison it is put into, which is the safe direction.

Checked arithmetic as a rule, not a habit. Overflow is reported. A wrapped sum in a schedulability test is the single worst arithmetic error available, because it converts a real failure into an apparent success.

No dependencies where none are needed. A crate that computes a bound should not pull in a runtime to do it.

No hardware measurements are published here. These crates compute bounds from execution times somebody else established, and a bound is only as good as its inputs — if those come from a spreadsheet rather than an oscilloscope, the result is arithmetic about a guess. The distinction is stated in each crate rather than left to a reader.

No comparative benchmark against other real-time platforms has been performed.

Denis Yermakou. Also the author of AxonOS, a real-time operating layer for brain–computer interfaces, where these problems arrived first and where the answers are used.

Apache-2.0 OR MIT for code, at your option. Every source file carries its SPDX identifier and its copyright line.