Timing analysis
with the arithmetic shown.
A measured maximum is not a worst-case bound. dy-wcet computes the bound, and shows every step of the arithmetic — so anyone can check it.
Two tasks.
Most answers are wrong.
What is the worst-case response time of task B?
R = 300 ⌈300/400⌉ = 1 → 300 ← fixed point
The window that counts is the response time, not the period. B finishes at 300 µs, and only one activation of A lands before it. Change the periods and the same mistake reports a deadline as met that is missed on hardware.
Try your own numbers
Meets its 1,000 µs deadline with 700 µs to spare.
The period-based count is pessimistic here. Change the periods and it can become optimistic, passing a set that misses.
R = 300 ⌈300/400⌉ = 1 → 300 ← fixed point
The same analysis as the crate for two tasks: the busy period first, then every job of B inside it, so a response that runs past the period is not under-reported. Checked against dy-wcet on 4,000 random pairs, including deadlines past the period. The schedule is a simulation of that scheduler, and it lands on the same finishing time as the analysis on 5,000 of 5,000.
It passes every utilisation check.
It still misses.
A second set: utilisation sits well under the classical bound, and one task misses its deadline by 70 µs — because the bound assumes a deadline equal to the period, and this one has none.
The theorem is not wrong. It answers a question nobody asked. The tool declines to apply it here rather than return the flattering answer.
For deadlines that are physical.
Where a missed deadline is a motor that overshoots, a sample that is lost, or a device that has to be recalled — not a slow page.
Firmware teams shipping real-time Rust
On Embassy, bare metal or an RTOS. Know whether a task set meets its deadlines before it reaches hardware, rather than after a field failure.
response_of · is_schedulableTeams defending a timing claim
A safety case under IEC 62304, ISO 26262 or IEC 61508 wants worst-case response times with a derivation behind them — integer, reproducible, checkable by hand.
every iteration shownRobotics, motor control, drones, BCI
Control loops where a late result is a physical event. Find how much a task can grow before something misses, and plan capacity against it.
max_provable_wcet_increasePeople building schedulers
An oracle to test admission control against: the same inputs, an answer derived separately, and a refusal wherever a figure cannot be justified.
optimal_priority_orderChecked, in public.
Every claim below links to the work behind it — including the time it went wrong.
An RP2350 timer that stopped for minutes
An intermittent embassy-time failure traced through alarm arming and timer-queue liveness, with evidence and hypothesis kept apart.
Read the analysis The time it went wrong557 confident wrong answers
The same review, run on my own tool, found it had reported 557 task sets as meeting deadlines they miss. Found, fixed, and still published in full.
Read the entry Cross-checkTwo implementations, one answer
A second response-time analysis, written separately, agrees on a set where the fixed point is not the first value tried.
See the derivationThe tool is free.
The audit applies it to your system.
dy-wcet is Apache-2.0 or MIT, and for debugging it is the right answer. When a timing claim has to hold up — to an investor, a customer or a certifier — DY Research applies it to your system and puts the verdict in writing.
Snapshot
What the technology actually does, and what its evidence supports.
See the scope Two to three weeksFocused Audit
One critical property — timing, determinism, concurrency — investigated to the bottom, with dy-wcet.
See the scope Three to four weeksDue Diligence
Whether the technology is what the company says it is, and what could break the investment.
See the scopeSend me the claim.
I will try to break it.
If your system claims deterministic or bounded latency, the audit answers one question in writing: does that claim survive someone trying to break it.