Rate Monotonic Analysis (RMA)

Transcription

1 Rate Monotonic Analysis (RMA) (Real-Time and Embedded System Laboratory) Major References: An Introduction to Rate Monotonic Analysis Tutorial Notes SEI MU* Distributed Real-Time System Design Using Generalized Rate Monotonic Theory Tutorial Notes Lui Sha SEI MU 99.* *The RMA Project is sponsored by the U.S. Dept. of Defense an we have a better way to predict the schedulability of a process set more precisely? Are we still able to predict the schedulability of a process set if the basic assumptions of rate monotonic scheduling [LL:73] are violated? Rate monotonic priorities Unique priority per unique period Preemptive scheduling Deadlines are coincident with start of period Only periodic tasks Do we have an analytical framework for reasoning the timing behavior of a process set or have an engineering basis for designing realtime systems.

2 Why are deadlines missed? For a given task consider the time needed by higher priority tasks the time needed to do this task s work delays caused by lower priority tasks priority inversion (blocking) To improve the performance of real-time systems identify and limit sources of priority inversion* *check previous examples 3 A Sample Problem Periodic tasks Servers τ τ τ 3 Emergency 50 msec 5 msec Aperiodic tasks Event handling task 40 msec msec 4 d:6 msec Desired respone 4 msec on average

3 Periodic Requirements Periodic task Ready to execute at fixed intervals deadline = the beginning of the next period (to be relaxed later!) Rate Monotonic Algorithm Assign higher priorities to tasks with shorter periods (to be relaxed later!) n If U( T ) n( ) for some n-process set T, T is schedulable [KM:9,LL:73]. 5 Periodic Requirements Task τ : =0, P =00, U =0. Task τ : =40, P =50, U =0.67 Task τ 3 : 3 =00, P 3 =350, U 3 = Total utilization: 75.3% U() 3 :3( ) = 77.9% 4.7% of the PU is usable for lowerpriority background computation! ADD more computation! 6

4 Periodic Requirements Task τ : =40, P =00, U =0.4 the utilization factor of the first two tasks: 66.7% < U(): 8.8% Total utilization: 95.3% > U(3)! The test result is inconclusive! τ τ τ 3 7 The Time Line of the Example 8 Improving the Schedulability Bound Theorem [LSD87]: A set of n independent periodic tasks scheduled by the rate monotonic algorithm will always meet its deadlines, for all task phasings, if and only if i.e., i, i n,min = { ( k, l) Ri R i i lp j j= k j lpk P ( k, l) k i, l =, Λ, P P } (min( ( k, l) Ri i j= lpk j Pj i lpk) 0) k

5 Improving the Schedulability Bound - Theorem Revisited Rate Monotonic Analysis (RMA) Basic Idea: Before time t after the critical instance of process τ i, a high priority process τ j may request amount of computation time. deadline of τ i 0 Formula: t Time i t Wi () t = c j j t d for some t in = i p j = = A sufficient and necessary condition and many extensions... Sha, An Intorduction to Rate Monotonic Analysis, tutorial notes, SEI, MU, 99 Improving the Schedulability Bound - Theorem Revisited A RMA Example: T(0,00), T(30,50), T3(80, 0), T4(00,400) T c <= 00 T c + c <= 00 or c + c <= 50 T3 c + c + c3 <= 00 or c + c + c3 <= 50 or c + c + c3 <= 00 or 3c + c + c3 <= 0 T4 c + c + c3 + c4 <= 00 or c + c + c3 + c4 <= 50 or... W3(t) Time

6 Improving the Schedulability Bound Reference: Theorem 3[JP86]: For a set of independent, periodic tasks, if each task meets its first deadline, with worst-case task phasings, the deadline will always be met ompletion Time (T) test Let W i =completion time of task i, W i may be computed by the following iterative formula Wi( n) Wi( n + ) = i + j, Wi(0) = 0 j< i Pj Task i is schedulable if its completion time is before its deadline. W i P (*Take P i as d i!!) i [LSD87] Lehoczky, Sha, and Ding, The Rate Monotonic Scheduling Algorithm-Exact haracterization and Average ase Behavior, TR, Dept. of statistics, LMU,987 [JP86] Joseph and Pandya, Finding Response Times in a Real-Time System, BS omputing Journal, vol 9, no.5, 986, pp Improving the Schedulability Bound an example Task τ : =40, P =00, U =0.4 Task τ : =40, P =50, U =0.67 Task τ 3 : 3 =00, P 3 =350, U 3 =0.86 Apply Theorem P > 00 or P > 50 or P > 00 or P * <= 300 * or P > 350

7 3 Apply Theorem 3 W 3 ( 0) = 0 0 W 3 ( ) = 3 + = 3 j = 00 j< 3 Pj W 3( ) = 3 + j j< P = = 80 3 j W 3 (3) = = W 3 (4) = = W 3 (5) = = The computation is converged! Θ W3 = 300 P3 = d3 = 350 Schedulable! Summary 4 Utilization bound test is simple but conservative. ompletion time test is more exact but also more complicated! In fact, tests based on Theorems and 3 have a pseudo-polynomial-time time complexity. To this point, UB, T, and Schedulability-Point tests share the same limitations. all tasks are periodic and not interacting with each another. deadlines are always the end of the period. no interrupts. rate monotonic priorities assigned. all tasks are on a single processor. zero context switch overhead. (stack dispelling) tasks do not suspend themselves.

8 Practical Applications Modeling context switching Schedulability with priority inversion Schedulability with Interrupts Schedulability without a rate monotonic priority Handling pre-period deadlines Important Issue: Identify the sources of blocking & manage them! 5 Modeling ontext Switching c RMA: c c Pure priority-driven preemptive schedules impose two scheduling actions per task (start of the period & end of the period) ci + s U i = P i 6

9 Modeling ontext Switching - Remark an it be more efficient than a cyclic executive? Run-time scheduling certainly appears to have more overhead than the scheduling overhead for a cyclic executive. But there is a hidden overhead in the cyclic case. Task periods must sometimes to be shortened to fit within the cyclic executive structure! Machine utilization increases, but not because more useful work is done! * yclic executive - where all work(tasks) fit into a common period (major frame) and executed non-preemptively. 7 Priority Inversion Delay to a task s execution caused by lowerpriority tasks is known as priority inversion. Systems potentially contain many sources of priority inversion. Identifying, reducing, and modeling priority inversion is central to schedulability analysis. 8

10 Priority Inversion Sources of Priority Inversion Non-rate-monotonic priority assignment (syntactically in RMA?!!) Non-preemptibility Interrupts Not enough priority levels FIFO queues (of course, they are more!) Synchronization 9 Schedulability with Interrupts Interrupt processing can be inconsistent with the RM priority assignment: Execute with a high priority despite long period! Delay execution of tasks with higher rate monotonic priorities. Source of priority inversion! 0

11 Schedulability with Interrupts Example Task : =0, P =00, U=0. Task : =40, P =50, U=0.67 Interrupt : int=60, Pint=00, Uint=0.3 Task 3 :3 =0, P3 =350, U3=0.057 Exec with RM priority Int The last task was not affected! Exec with an Interrupt priority Int Schedulability with Interrupts Solution Should interrupts be modeled in the same manner as task s context switching (i.e., treated as extra execution time)? int Int Int Int Int =+int=80 = =0

12 Schedulability with Interrupts The completion time for is correct! orrect model for. fails! Θ It is too pessimistic for. should be affected at most once per period! fails! is preempted too frequently! onsider each task separately! 3 Rule of Thumb Task schedulability is affected by Preemption effects: Potentially many times per period. Execution effects: Once per period! Blocking effects: at most once per period for each source of blocking *Blocking effects occur at a lower frequency, and thus each blocking effect can impact the task only once per period. 4

13 Schedulability with Interrupts Solution : Modeling Interrupts with Blocking Time Example: τ : =0,P =00,U =0. τ : =40,P =50,U =0.67 τ int : int =60,P int =00,U int =0.3 τ3: 3 =0,P 3 =350,U 3 = τ + int Int = P For τ τ τ Int + int + = 0.86> U() = 0.88 For τ P P 5 Schedulability with Interrupts τ τ τ int Int Int For τ 3 τ int = 0.84 > U (4) = P P P P int (Harmonic base size = 3 U(3)=0.779) 6 P *(3) int = int

14 Apply Theorem For τ : R ={(,),(,)} + + B = int = 0 > P + + B = int = 40 P τ : = 0, P = 00, U = 0. τ : = 40, P = 50, U = 0.67 τ int : int = 60, P int = 00,U int = 0.3 Apply Theorem 3 For τ : ω (0) = 0 ω () = + B + j < [0] p j j 7 = + B = 00 ω () = + B + j< 00 < P j j = + B + = 0 ω (3) = + B = + B + = 40 ω (4) = + B = + B + = 40 ω = 40 < d = P = 50 8

15 Summary This modeling technique can be used to model: Interrupts Non-preemptibility Non-rate-monotonic priorities -Find priority based on pre-period deadline -Jitter requirement (e.g. high priority I/O-related execution) Theorem : j < i P j j + i + B i P i U ( i) 9 Theorems and 3: Include B i in the computation time of τ i when the schedulability of τ i is under consideration! 30 Non-Rate-Monotonic Priority Assignment Example : Preemption/Exec/Blocking Effects T T5-Preemption Effects:, T T6-Preemption Effects:,, 5 T7-Preemption Effects:,, 6 T3 (assume no changes over priority order) T4 T3: T5 Preemption Effects:, Execution Effects: 3 T6 Blocking Effects: T7 T8

16 3 Non-Rate-Monotonic Priority Assignment Example : Limited Priority Levels T T T: Preemption: none Execution: Blocking: T3 T: T4 Preemption: T5 Execution: Blocking: none T6 T3: T7 T8 Preemption:, Execution: 3 Blocking: 4 3 Non-Rate-Monotonic Priority Assignment Example 3: Preemption/Exec/Blocking Effects T T T3 T4 T5 T6 T7 T8 T T T5 T8 T6 T3 T4 T7 T6: Preemption:,, 5 Execution: 6 Blocking: 8 T7: Preemption: -6 Execution: 7 Blocking: 8

17 Techniques for Handling Pre-Period Deadlines Insert dormant time τ τ For τ &τ D P d = = 0 τ τ τ 3 For τ 3 33 Techniques for Handling Pre-Period Deadlines - Insert dormant time P P + + P + D P + P 3 3 = = = U () = U (3) 34

18 Techniques for Handling Pre-Period Deadlines 35 Apply critical-zone analysis. Determine the worst-case completion time. ω ω ω ω ( 0 ) () ( ) ( 3 ) ω = = = = j < j = + = ( 0 ) P.ompare worst-case completion time with the pre-period deadline. ω = 60 d = = j + = 30 = = Another thought about the calculation of worst-case completion! ω ( n + ) = i i + ω i ( n) j + Bi P τ jhas a priority higher than τ i j exec preemption blocking caused by Incrementally increase priority if needed!!. If the task can not meet a specified pre-period deadline, then raise its priority & try again! non-rate-monotonic priority!.use the same analysis as for interrupts onsider the schedulability of all critical tasks!

19 Measurement Issues ommon misconception: The rate monotonic analysis seems to be useful only if accurate execution times are available! In fact, the rate monotonic analysis is forgiving to inaccurate measurement: Importance of accuracy is relative to the length of the period. (deadline) One is more likely to have better estimates for higher frequency tasks. Robust to change!! 37 Measurement Issues The issue of inaccurate execution time is not specific to the rate monotonic analysis approach; it is inherent to hard real-time systems! The rate monotonic approach, however, highlights the parameters of importance. higher-priority execution times blocking times, and execution time 38

20 Treatment of Synchronization Requirements Synchronization Priority Inversion 39 Identifying, modeling, and reducing sources of priority inversion is central to schedulability analysis!! Source of Priority Inversion non-preemptible regions of code interrupts non-unique priorities for some tasks non-rate-monotonic assignment of task priorities FIFO of any other non-priority-based queues Synchronization and mutual exclusion Remark: Blocking effects(usually) occur at a lower rate, and thus each blocking effect can impact a task(usually) at most once per period. 40

21 Synchronization Protocols. No preemption ritical sections are executed at an infinitely high priority! τ L τ M Time τ H Note that τh & τm have no intention to enter a critical section! 4 Synchronization Protocols.Highest locker s priority Execute critical section at the priority of the highest-priority task that may lock the semaphore(/resource); higher-priority tasks may preempt the critical section. τ L τ M τ H Time τ vh Note that τ vh is no longer blocked by τ L 4

22 Synchronization Protocols 3. Basic Inheritance Protocol (BIP) Execute the critical section at the priority of the highest-priority task being blocked; higher-priority tasks may preempt the critical section. τ L τ M τ H S S S blocked S blocked S & S S S Time τ vh t 43 -Note that τ M is no longer blocked until necessary. - However, system may be deadlocked or have chained blocking! Synchronization Protocols 4. Priority eiling Protocol BIP + a Priority eiling rule about when to grant lock requests (see [Sha 87, 90] ) τ L τ M τ H S S blocked S blocked S S Time τ vh 44 - No deadlock & chained blocking at the cost of reducing the concurrency level of the system. - Blocked-at-most-once.

23 Synchronization Protocols Schedulability tests for Basic Inheritance Protocol (BIP) 45 P () + = U P B + D B + + U P P P () 3 P P P U ( ) 0 50 * In PP B = max(0,0) = = Synchronization Protocols Schedulability tests for Non-preemptible ritical Sections B = + = P P D B = + + = U () = 0.88 P P P P + 3 U P P3 () 3 46

24 Synchronization Protocols a comparison Bounded Priority Nonpreemptible ritical Sections Blocked at Most Once Inversion Yes Yes Yes Deadlock Avoidance Highest Locker s Priority Yes Yes Yes BIP Yes No No PP Yes Yes Yes 47 Tasks suspending themselves inside critical sections will hand over PU to (lowerpriority) tasks. The later may lock other resources. Tasks suspending themselves between critical sections shall not be protected! 3Reasons for task suspensions: I/O Aperiodic Servers Aperiodic tasks runs at irregular intervals Aperiodic deadline hard, minimum inter-arrival time. Soft, best average response time. Services such as operator requests device interrupts... 48

25 Scheduling Aperiodic Tasks Polling ~ Average Response Time = 50 units Interrupt Handler ~ Average Response Time = unit 0 00 Deferrable Server [Lehoczky87] ~ Average Response Time = unit An on-demand service type When execution budget is used up, server execution drops to a lower (background) priority until the budgeted execution time is replenished. Deferrable Server (DS) [Lehoczky87] τ as a DS server to preserve PU bandwidth for a collection of aperiodic tasks. τ has an entire period to use its run-time and gets replenished at the beginning of each of its period. Theorem 3 [Lehoczky87]: For τ as the highest priority DS server, and τ τ n as periodic tasks, the achievable utilization factor when n U + /( n ) U + U = U + ( n )[( ) ] U = U+ ln( ) U + U + U is minimized to when U = J.P. Lehoczky, L. Sha, and J.K. Strosnider, Enhancd Aperiodic Responsiveness in Hard Real-Time Environment, RTSS 87, pp

26 Remarks: Deferrable Servers: fixed execution budget replenishment interval priority adjusted to meet requirements. Note that the response time performance improves as the replenishment rate decreases because the execution budget increases and more services can be provided. Polling: From the scheduling point of view, polling converts the servicing of aperiodic events into an equivalent periodic tasks. Not an on-demand service type. As the rate of polling increases, the response time for polling approach improves. The rationale behind aperiodic servers: No system benefit to finish periodic work early! 5 Sporadic Server [Sprunt et. al. 90] Modeled as periodic tasks fixed execution budget(c) replenishment interval (p) Execution Budget P=00ms 00ms Replenishment occurs one period after the start of usage! Priority adjusted to meet requirements. 5

27 Sporadic Server [Sprunt et. al. 90] A sporadic server differs from a deferrable server in its replenishment policy A 00 msec deferrable server replenishes its execution budget every 00 msec, no matter when the execution budget is used. The affect of a sporadic server on lower priority tasks is no worse than a periodic task with the same period and execution time. 53 Sporadic Server [Sprunt et. al. 90] A sporadic server (SS) under the fixedpriority scheduling framework. Terms: Ps: the priority at which the system is executing. Pi: one priority level in the system. Active: A priority level Pj is active is Pj <= Ps. Idle: not active RTi: replenishment time for SS executing at priority level Pi 54 Brinkley Sprunt, Aperiodic Task Scheduling for Real-Time Systems, Ph.D. Thesis Dept. of Electrical and omputer Engineering, arnegie Mellon University, August 990.

28 Sporadic Server [Sprunt et. al. 90] Rules: Replenishment Time RTi If SS has execution time available, and Pi becomes active at time t, then RTi = t + Pi. If SS s execution time is exhausted, and SS s execution time becomes non-zero (is replenished) at time t and Pi is active, then RTi = t + Pi. Replenishment Amount Determined when Pi becomes idle or SS s execution time has been exhausted. The amount is equal to the amount of server execution time consumed since the last time at which the status of Pi changes from idle to active. 55 Sporadic Server [Sprunt et. al. 90] Important theorems: Theorem [Sprunt90:p8]:Given a real-time system composed of soft-real-time aperiodic tasks and hard real-time periodic tasks, let the soft real-time aperiodic tasks be serviced by a polling server that starts at full capacity and executes at the priority level of the highest priority periodic task. If the polling server is replaced with a sporadic server having the same period, execution time, and priority, the sporadic server will provide high-priority aperiodic service at times earlier than or equal to the times the polling server would provide high-priority aperiodic service. 56

29 Sporadic Server [Sprunt et. al. 90] Theorem 5 [Sprunt90:p34]: A periodic task set that is schedulable with a periodic task Ti, is also schedulable if Ti is replaced by a sporadic server with the same period and execution time. Schedulability analysis of sporadic servers is equivalent to periodic tasks! -> overcome the penalty paid by the deferrable servers! Remark In terms of server size, the sporadic server approach is better than the deferrable server approach. Although the sporadic server approach claims low implementation overhead, it seems to be a little bit higher than the deferrable server approach. If aperiodic services are requested very heavily, the differences between DS and SS will diminish. 57 A Sporadic Server Example 58

30 Aperiodic Task Processing A ompasion A task set example Periodic task = P=4 Periodic task/ deferrable server/ sporadic server = P=5 Periodic task3 3=3 P3=0 Periodic task executions τ τ τ Aperiodic Task Processing A ompasion 60 deferrable server execution Aperiodic Instant Request Time τ τ DS apacity τ miss τ3 needs one more computation time.

31 Aperiodic Task Processing A ompasion sporadic server execution τ τ SS apacity RT 8 Instant RTime τ Note that the 3rd and 4th requests response times are delayed by 3 & time units in this case, respectively. 6 Sample Problem: aperiodic tasks Emergency events 5 ms of work arrives every 50ms, worst case hard deadline 6ms after arrival Emergency Server (ES) a sporadic server i = 5 ms P i = 50 ms (replenishment interval) 6

32 Sample Problem: aperiodic tasks routine event ms of work on average arrives every 40ms on average desired average response of 4ms after arrival. Routine Server (RS) a sporadic server i = 0 P i = 00 ms (replenishment interval) 63 Sample Problem: aperiodic tasks How to derive it?! Using M/M/ queuing approximation Response Time avg = apacity = ServiceTime Workload ( apacity avg avg ) Workload avg = ServiceTime avg InterArrivalTime Re sponsetimeavg * ServiceTimeavg IntervalArrivalTime (Re sponsetime ServiceTime avg avg avg avg ) 4* apacity = = 0. = 40(4 ) Budget Interval But what replenishment interval we should pick up?? 50ms, 80ms, 00ms,00ms, Take 00ms and make RS s priority > any periodic τ i s priority. 64

33 Sample Problem: all tasks Now we have the following sample problem: (BIP) ES RS P D B U Harmoically related! τ τ = 40/50 τ = 00/ UB Test τ Sample Problem: all tasks ( * 5) = 0.7 <.00? τ (*5) = 0.867> U() = ? 66 τ 3 (*5) = 0.953> U(3) = If PP is used B=max(0,0)=0 instead of 30.

34 Sample Problem: all tasks τ T Test for W (0) W B 0 = = W () = = W 3 * ( ) = + + P 90 () = = Since W = 90 P D = 50 0 = 30 Done 67 Summary Rate monotonic analysis offers a general framework for considering timing issues through the life cycle ~ early detection and minimization of priority inversion. Implementation: schedulability analysis facilitates separation of concerns Testing identification of bottlenecks discovering of timing errors Post-deployment easy to understand effects of changes. 68