1. Real-time Embedded Systems Rate monotonic theory scheduling

2. P RIORITY P REEMPTION S CHEDULING A task runs until either it suspends itself or is preempted by a higher priority task. Usually RTOS can guarantee a worst case time for interrupt recognition and handling Guaranteed response time for highest priority task only (if certain conditions occur) interrupt event interrupt service time scheduling time Worst case task execution time (guaranteed minimum for highest priority task) output action at guaranteed time

3. P RIORITY P REEMPTION S CHEDULING For worst case execution time to be calculable : a) Maximum limit of iterations for each loop b) No recursion c) No use of dynamic data structures Further complication: what if a process requires a shared resource or device to complete its action? We must either pre-allocate or take into account the maximum delay involved waiting for the resource or device.

4. P ERIODIC T ASKS A Task has execution time C and period P A set of periodic tasks is said to be schedulable if all its deadlines are met. i.e. every periodic task finishes its execution before the end of its period. Tasks are independent if their executions need not be synchronised Note to be executable at all, utilisation :

5. R ATE M ONOTONIC S CHEDULING R ATE M ONOTONIC S CHEDULING ** Applies to periodic tasks Use priority pre-emption so we can use it with existing schedulers Theory ensures that as long as the CPU utilisation lies below a certain bound all tasks meet deadlines =>Rigorous approach to timing correctness Scheduling Strategy Assign each periodic task a priority which is inversely proportional to its period i.e. task with shortest period gets highest priority Priority 1/period

6. R ATE M ONOTONIC T HEORY R ATE M ONOTONIC T HEORY ** Sufficient (worst case) condition ** Liu C.L. & Layland J. 1973, " Scheduling algorithms for multiprogramming in a hard real-time environment, Journal of the ACM, 20(1), pp46-61, 1973

7. R ATE M ONOTONIC S CHEDULING

8. R ATE M ONOTONIC S CHEDULING - EXAMPLE The bound of Theorem 1 is in fact very pessimistic because the worst-case task set is contrived and unlikely to be met in practice. For a randomly chosen task set, the likely bound is 88 percent. Lui Sha & John B. Goodenough, "Real-time Scheduling Theory and Ada", IEEE Computer, April 1990

9. RMT S CHEDULING: C RITICAL Z ONE T HEOREM To know if a set of given tasks with utilisation greater than the bound of Theorem 1 can meet its deadlines, we can use an Exact schedulability test based on theorem 2:

10. RMT S CHEDULING: C RITICAL Z ONE T HEOREM Critical Zone Theorem requires that we check that each task can complete its execution before its first deadline. To do this, we need to check the Scheduling Points for a task. The Scheduling Points for task T are: T's first deadline & ends of periods of higher priority tasks prior to T's first deadline.

11. R ATE M ONOTONIC S CHEDULING - EXAMPLE By Theorem 1, T1 & T2 are schedulable 0.667  U(2) = 0.828 Use Theorem 2 for T3 to check SET is schedulable. Note: we’ve made it harder by increasing T1’s computation

12. U SING T HEOREM 2 - EXAMPLE Sufficient to show that all tasks meet their deadline for one scheduling point for the set to be schedulable. Since the tasks meet their deadlines at least once within the period T3 then by Theorem 2 they will always meet them.

13. U SING T HEOREM 2 - EXAMPLE T3's first deadline & ends of periods of higher priority tasks prior to T3's first deadline. 350

14. SCHEDULING POINT CHECKS Take HCF of all task periods. Check at each period & multiple of HCF k= 1, 2, 3, … Until longest period (last deadline) is found. If they do not fit by then then they will not. Remember sum is: (c is compute time) m.T1c + n.T2c + p.T3c … ≤ k.HCF Where m,n,p.. are the number of times the task has to run before deadline k.HCF

15. R ATE M ONOTONIC T HEORY Advantages: Separates LOGICAL & TIMING correctness Simple to verify correctness of new tasks. Disadvantages: Jitter : guarantee to execute a task within its period, No guarantee when in the period it is executed May change between repeated executions. Use RMT to guarantee values produced in time, and hardware (or OS clock/timer) output at specific times any alternative?

16. D ESIGN U SING RMT: I SSUES STILL TO DO Integration with background (non-essential) tasks Handling aperiodic tasks (safety critical & essential) and somewhat more complex, handlingPeriodic Task interactionAperiodic Task interaction and linking the whole lot together

17. S TABILITY U NDER RM S CHEDULING 1 Assumption so far: Tasks require constant amount of computation However usually average computation is less than worst case Can use processor time for non-essential tasks (running at lower priorities)

18. S TABILITY U NDER R M S CHEDULING 2 A scheduling algorithm is considered to be stable if a set of tasks exist such that all tasks in set will meet their deadlines even if the central processor is overloaded † † greater demand for CPU time than available time *The rate monotonic algorithm is stable Tasks guaranteed to meet their deadlines under worst-case executions times are the n highest priority tasks. = schedulable set

19. S TABILITY U NDER R M S CHEDULING 3 If we know the worst case execution times & periodicity, we can calculate a schedulable set using either Theorem 1 or 2: Run non-essential tasks at priorities outside the Schedulable Set T1 T2 T3 T4 T5 … Tasks Priority High Low

20. M OST I MPORTANT T ASK N OT H IGHEST P RIORITY ? In Rate Monotonic Scheduling, the highest priority goes to tasks with the shortest periods. What happens to a critical task with a long period P L ? It falls outside the schedulable set.

21. S OLUTION : P ERIOD T RANSFORMATION Give the task a period P L /2, and suspend it after it executes half its worst-case execution time = C/2 Task is then resumed and finishes its work in next execution period. Task has same utilisation but shorter period and thus higher priority.

22. A PERIODIC T ASKS 1 Need to meet both: regular deadlines of periodic tasks and response time requirements of aperiodic requests Aperiodic servers are tasks used to process these aperiodic requests. Example: T1 has period 100 and execution time 99 T2 is a server for an aperiodic request - service time = 1 unit Suppose an aperiodic request randomly arrives once in a period of 100

23. A PERIODIC T ASKS: S OLUTION 1 a) Let aperiodic task run in background (i.e. lower priority) = polling server providing: 1 unit of service time in each period of 100

24. A PERIODIC T ASKS: S OLUTION 2 b) Allow T2 to preempt T1 for fixed budget of time in each 100 ms period task T2 -- priority = high loop accept request --service request delay until start of next 100ms period end Average response time ≈ 1 T1 deadline still guaranteed

25. S PORADIC S ERVERS 1 Guarantee deadlines while supporting aperiodic requests Allocate server budget of service time C in a set period P For RMS, server is treated as a periodic task with period P & worst case execution time C i.e. Utilisation = C/P When the server has used up its budget: Either suspend it or reduce its priority such that it cannot interrupt periodic tasks. But then in overload situations the sporadic server may not meet response time deadlines

26. S PORADIC S ERVERS 2 task sporadic_server tickets = budget;{B = budget * service time} loop accept request; -- service request tickets:=tickets-1; if tickets=0 then -- either delay or reduce priority until replenish time* end loop end task * r t: may be at fixed points P, 2P, 3P… or P units after budget exhausted

27. S PORADIC S ERVERS EXAMPLE 1: a A verage request inter-arrival time is 40 ms. Time to service a request is 2 ms and desired average response time is 4ms. An essential rather than a time critical service. Suppose we implement this service with a sporadic server with period 100ms & computation budget 10ms

28. S PORADIC S ERVERS EXAMPLE 1: b Server: period 100ms, computation budget 10ms Server capacity = 10/100 = 0.1 Average workload = 2/40 = 0.05 Average server utilisation  = 0.05/0.1 = 0.5 Assume Queueing Theory M/M/1 approximation for lightly loaded server Avg response Time = ServiceTime/(1-  ) = 2/(1-0.5)= 4ms remember: equations can be used backwards!

29. T IME- C RITICAL A PERIODIC R EQUESTS The event service must be finished 6 ms after its arrival Time to service = 5 ms Worst Case Event Inter-arrival time = 50ms To guarantee this deadline: sporadic server with period 50 ms & computation budget 5ms.If this has highest priority, then deadline is guaranteed. This is how we can include interrupts & interrupt service routines in the schedulability analysis. Need to know the worst case interrupt inter-arrival time and the Interrupt service time