Toolgeist › Developer

Real-Time Scheduling Analyzer — Rate Monotonic vs EDF

Enter your periodic tasks and find out whether they actually meet their deadlines. This runs the Liu & Layland sufficient bound U ≤ n(2^{1/n}−1), the exact Rate Monotonic test by response time analysis, and the EDF utilisation test that is both necessary and sufficient for implicit deadlines — then simulates the schedule preemptively over the hyperperiod so you can see the timeline rather than trust a formula. The analytic verdicts and the simulation were cross-checked against each other on 241 random task sets and agreed every single time.

How to use Real-Time Scheduling Analyzer — Rate Monotonic vs EDF

  1. Load a preset or type your own worst-case execution times and periods.
  2. Compare the Rate Monotonic verdict against the EDF verdict.
  3. Read each task’s response time R against its deadline.
  4. Switch the simulation between RM and EDF to see where a deadline is actually missed.

Frequently asked questions

My utilisation is above the Liu & Layland bound — am I doomed?
No. That bound is sufficient, never necessary: it is the worst case over all possible period relationships. Load the harmonic preset and you will see utilisation at exactly 100% with Rate Monotonic still meeting every deadline, because each period divides the next. Failing the bound tells you nothing on its own; only exact response time analysis gives a verdict.
What is response time analysis actually computing?
The longest time a task can take to finish once released, accounting for every preemption by higher-priority tasks. It solves R = C + Σ⌈R/T_j⌉·C_j by iteration until the value stops changing. If that fixed point is within the deadline the task is safe; if the iteration runs past the deadline it never converges, which is exactly what a miss looks like.
If EDF achieves 100% utilisation, why does industry still use Rate Monotonic?
Because fixed priorities are simple to implement, cheap at runtime, and predictable under overload — the lowest-priority task degrades first and you chose which task that is. EDF under overload can miss deadlines unpredictably across the entire task set, and dynamic priorities make post-mortem timing analysis much harder. Most RTOS kernels and automotive standards assume fixed priorities for these reasons.
What does U > 100% mean?
That the processor is oversubscribed in the most literal sense: the tasks demand more execution time than exists. No scheduling algorithm can help, and the only fixes are reducing execution times, lengthening periods, or adding a processor.
What does this model ignore?
Quite a lot that matters in practice: context-switch overhead, interrupt handlers, shared resources and the blocking they cause, cache effects that make worst-case execution time genuinely hard to estimate, and multicore — where these elegant single-processor results simply do not carry over. Treat it as a first-pass feasibility check.
What is priority inversion?
When a high-priority task waits on a resource held by a low-priority task, which is itself preempted by a medium-priority task — so the medium task effectively outranks the high one. It nearly ended the Mars Pathfinder mission in 1997. Priority inheritance protocols solve it, and none of that is captured by the independent-task model used here.

Related Developer tools

Also searched for: rate monotonic scheduling calculator · edf vs rate monotonic · liu layland bound calculator · response time analysis real time · schedulability test periodic tasks

Browse all 738 free tools on Toolgeist →