Rate-monotonic scheduling, or RMS, is a rule for assigning priorities to periodic tasks in a real-time system: the more often a task must run, the higher its priority. A task with a short period, meaning it repeats frequently, is given precedence over a task with a longer period. Once priorities are fixed by this rule, an ordinary fixed-priority preemptive scheduler does the rest.
The scheme comes from C. L. Liu and James W. Layland’s 1973 paper in the Journal of the ACM, “Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment” (volume 20, number 1, pages 46 to 61). Studying single-processor scheduling for tasks needing guaranteed service, they proved that the rate-monotonic priority assignment is optimal among all fixed-priority schemes: if any fixed-priority ordering can schedule a set of periodic tasks so that all deadlines are met, then the rate-monotonic ordering can too.
The paper’s most cited result is its utilization bound. Liu and Layland showed that the rate-monotonic scheduler is guaranteed to meet every deadline as long as total processor utilization stays below a bound that depends on the number of tasks, a bound that approaches about 69 percent (the natural logarithm of 2) as the number of tasks grows large. This gives engineers a simple, conservative test: keep the CPU below that threshold and the schedule is provably safe, without having to simulate every possible timing of events.
The same paper introduced the alternative of assigning priorities dynamically by nearest deadline, earliest deadline first, and showed it can drive utilization all the way to 100 percent. The trade is the one that still defines real-time scheduling: rate-monotonic is simpler, more predictable, and easier to certify, while deadline-driven scheduling reclaims the wasted headroom at the cost of complexity.
Rate-monotonic analysis became a standard tool for designing hard real-time systems, used to verify that flight software, control loops, and other deadline-bound workloads will keep their guarantees. It remains one of the few places in software where a designer can prove, rather than merely test, that the system will always meet its timing requirements.