G 572 Realtime Systems Rate Monotonic Analysis Xinrong

  • Slides: 94
Download presentation
G 572 Real-time Systems Rate Monotonic Analysis Xinrong Zhou (xzhou@abo. fi) Real-Time System Rate

G 572 Real-time Systems Rate Monotonic Analysis Xinrong Zhou (xzhou@abo. fi) Real-Time System Rate Monotonic Analysis 1

RMA § RMA is one quantitative method which makes it possible to analyze if

RMA § RMA is one quantitative method which makes it possible to analyze if the system can be scheduled § With the help of RMA it is possible to: § select the best task priority allocation § select the best scheduling protocol § Select the best implementation scheme for aperiodic reality § If RMA rules are followed mechanically, the optimal implementation (where all hard deadlines are met) is reached with the highest possibility Real-Time System Rate Monotonic Analysis 2

RMA § System model § scheduler selects tasks by priority § if a task

RMA § System model § scheduler selects tasks by priority § if a task with higher priority comes available, task currently running will be interrupt and the task with higher priority will be run (preemption) § Rate Monotonic: priority controls § monotonic, § frequency (rate) of a periodic process Real-Time System Rate Monotonic Analysis 3

Contents § 1. 2. 3. 4. Under what conditions a system can be scheduled

Contents § 1. 2. 3. 4. Under what conditions a system can be scheduled when priorities are allocated by RMA? Periodic tasks Blocking Random deadlines Aperiodic activities Real-Time System Rate Monotonic Analysis 4

Why are deadlines missed? § Two factors: 1. The amount of computation capacity that

Why are deadlines missed? § Two factors: 1. The amount of computation capacity that is globally available, and 2. how this is used § Factor 1 can be easily quantified § § § Factor 2 contains § § § MIPS Max bandwidth of LAN Processing capacity that is used by the operating system Distribution between tasks RMA goals: § § Optimize distribution in such a way that deadlines will be met; or ”provide for graceful degradation” Real-Time System Rate Monotonic Analysis 5

Utilization § Task Ti is dependent on: 1. Preemption of tasks with higher priority

Utilization § Task Ti is dependent on: 1. Preemption of tasks with higher priority § describes relative usability grade of tasks with higher priority 2. Its own running time § ci 3. blocking by tasks with lower priority Ø Lower priority tasks contain critical resources Real-Time System Rate Monotonic Analysis 6

Example Task runtime ci period Ti Utilization Priority Total utilization U = 88, 39%

Example Task runtime ci period Ti Utilization Priority Total utilization U = 88, 39% T 1 3 9 33, 33% 3 T 2 5 15 33, 33% 2 T 3 5 23 21, 73% 1 3 3 3 5 3 1 3 2 1 23 20 Missed deadline 10 Real-Time System Rate Monotonic Analysis 7

Harmonic period helps § Application is harmonic if every task’s period is exact portion

Harmonic period helps § Application is harmonic if every task’s period is exact portion of a longer period Task runtime ci period Ti Utilization Priority Total utilization U = 88, 32% T 1 3 9 33, 33% 3 T 2 6 18 33, 33% 2 T 3 8 36 21, 66% 1 3 3 3 6 6 10 2 20 Real-Time System 30 36 Rate Monotonic Analysis 8

Liu & Layland § Suppose that: 1. Every task can be interrupted (preemption) 2.

Liu & Layland § Suppose that: 1. Every task can be interrupted (preemption) 2. Tasks can be ordered by inverted period: Ø pr(Ti) < pr(Tj) iff Pj<Pi 3. Every task is independent and periodic 4. Tasks relative deadlines are similar to tasks’ periods Ø Only one iteration of all tasks is active at one time! Real-Time System Rate Monotonic Analysis 9

Liu & Layland § When a group of tasks can be scheduled by RMA?

Liu & Layland § When a group of tasks can be scheduled by RMA? § RMA 1 § If total utilization of tasks can be scheduled so that every deadline will be met e. g. When the number of tasks increases, processor will be idling 32% of time! Real-Time System Rate Monotonic Analysis 10

Variation of U(n) by n Real-Time System Rate Monotonic Analysis 11

Variation of U(n) by n Real-Time System Rate Monotonic Analysis 11

Example § In example below, we get utilization 6/15+4/20+5/30 = 0, 767 § because

Example § In example below, we get utilization 6/15+4/20+5/30 = 0, 767 § because U(3) = 0, 780, application can be scheduled Task running time ci period Ti Utilization Priority T 1 6 15 0, 4 3 T 2 4 20 0, 2 2 T 3 5 30 0, 167 1 Real-Time System Rate Monotonic Analysis 12

Why shorter periods are prioritized? Task runtime ci period Ti non RMA priority T

Why shorter periods are prioritized? Task runtime ci period Ti non RMA priority T 1 3 5 1 2 T 2 4 10 2 1 T 1 misses deadline 0 5 T 1 In realistic application. c is small compared with T. Shortest T first ensures that negative preemption effects will be minimized T 2 10 non RMA Real-Time System Rate Monotonic Analysis 13

Why shorter periods are prioritized? § Slack: T-c = S § In example is

Why shorter periods are prioritized? § Slack: T-c = S § In example is c 2 > T 1 – c 1 § In practice is c<< T e. g. slack is proportional to the period § By selecting the shortest period first, the preemption effect will be minimized § NOTE: § We are primarly interesting in shortening deadlines by priorities! Real-Time System Rate Monotonic Analysis 14

How 100% utilization can be achieved? § Critical zone theorem: § If some number

How 100% utilization can be achieved? § Critical zone theorem: § If some number of independent periodic tasks start synchronously and every task meets its first deadline, then every future deadline will be met § Worst-case: task starts at the same time with higher-priority task § Scheduling points for task Ti: Ti’s first deadline, and the end of periods within Ti’s first deadline for every task with higher priority than Ti § If we can show that there at least one scheduling point for one task, then if that task have time to run one time, this task can be scheduled Real-Time System Rate Monotonic Analysis 15

Lehoczky, Sha and Ding § Idea: test every scheduling points RMA 2: Real-Time System

Lehoczky, Sha and Ding § Idea: test every scheduling points RMA 2: Real-Time System Rate Monotonic Analysis 16

Lehoczky, Sha and Ding Real-Time System Rate Monotonic Analysis 17

Lehoczky, Sha and Ding Real-Time System Rate Monotonic Analysis 17

Example Task running time ci period Ti Utilization Priority T 1 40 100 0,

Example Task running time ci period Ti Utilization Priority T 1 40 100 0, 4 3 T 2 40 150 0, 27 2 T 3 100 350 0, 29 1 § Utilization is 0, 953 § U(3) = 0, 779 § By RMA 1 tasks are not schedulable Real-Time System Rate Monotonic Analysis 18

Analysis using RMA 2 200 100 40 150 40 40 40 300 40 20

Analysis using RMA 2 200 100 40 150 40 40 40 300 40 20 60 Real-Time System Rate Monotonic Analysis 19

Real-Time System Rate Monotonic Analysis 20

Real-Time System Rate Monotonic Analysis 20

Overhead § Periodic overhead § overhead to make tasks periodic § overhead to switch

Overhead § Periodic overhead § overhead to make tasks periodic § overhead to switch between tasks § System overhead § overhead of operating system § UNIX, Windows NT: difficult to know what happens in background Real-Time System Rate Monotonic Analysis 21

Periodic Overhead § To execute a task periodically, the clock must be read and

Periodic Overhead § To execute a task periodically, the clock must be read and the next execution time must be calculated Next_Time = Clock; loop Next_Time = Next_Time + Period; {. . . periodic task code here. . . } delay Next_Time – Clock; end loop § task switch: § saving and recalling tasks ”context” Öadd two task switches to the running queue Real-Time System Rate Monotonic Analysis 22

Periodic Overhead § Data can be gathered by benchmarking § for e. COS operating

Periodic Overhead § Data can be gathered by benchmarking § for e. COS operating system with: § Board: ARM AEB-1 Evaluation Board § CPU : Sharp LH 77790 A 24 MHz Confidence Ave Max Var Ave Min Function 125. 56 102. 67 148. 00 11. 89 50% 25% Create thread 75. 16 74. 00 211. 33 2. 13 99% Thread switch 45. 69 44. 00 46. 00 0. 38 95% 135. 33 160. 00 1. 96 95% 0. 49 70% 136. 53 42. 58 Min 36. 67 43. 33 4% Resume [suspended low prio] thread 95% Resume [high priority] thread 4% Suspend [runnable] thread Real-Time System Rate Monotonic Analysis 23

Overhead § The whole overhead can be also measured by benchmarks § Program schedules

Overhead § The whole overhead can be also measured by benchmarks § Program schedules tasks and measures the processing time § overhead = 100 - available processing capacity for an application § Example: Ø PC Pentium 166, Windows 98, Alsys Object Ada: 65% / k. Hz Ø CETIA VMTR 2 a, Power. PC 604, 100 MHz, Lynx. Os 2. 4 Alsys Object Ada: 19% / k. Hz § RMA 1 § Q = Overhead in application Real-Time System Rate Monotonic Analysis 24

Example Task running time ci period Ti Rate Utilization Priority T 1 6 15

Example Task running time ci period Ti Rate Utilization Priority T 1 6 15 66 0, 4 3 T 2 4 20 50 0, 2 2 T 3 5 30 33 0, 1667 1 § § rate is 150 : overhead is 2, 85% (19% / k. Hz) U(3) = 0, 780 – 0, 0285 = 0, 752 Utilization = 0, 767 System is not schedulable using RMA 1 Real-Time System Rate Monotonic Analysis 25

Overhead § It is also possible to add the overhead directly to the every

Overhead § It is also possible to add the overhead directly to the every task § 19% / k. Hz is equivivalent with 190 s / job § RMA 1 § RMA 2 Real-Time System Rate Monotonic Analysis 26

Transient overloading (Busy Intervals) § Check the following example: Task WCET ci average run

Transient overloading (Busy Intervals) § Check the following example: Task WCET ci average run time ai period Ti T 1 20 10 100 T 2 30 25 150 T 3 80 40 210 T 4 100 20 400 Uwcet=1, 03 Uaverage=0, 51 U{T 1, T 2, T 3}=0, 78 § Tasks are not schedulable by RM using WCET (Worst Case Execution Time), but they are schedulable using average running time § Suppose that T 1, T 2, T 4 are critical tasks and T 3 is not a critical task Real-Time System Rate Monotonic Analysis 27

Transient overloading § Solution: § increase T 4 ’s priority by decreasing period Ø

Transient overloading § Solution: § increase T 4 ’s priority by decreasing period Ø T 4’ with parameters: c’ 4 = c 4/2, a’ 4 =a 4/2, T’ 4 = T 4/2 Ø now T 4’ has higher priority than T 3 Ø then T 4’ scheduled to run instead of T 4 Ø if {T 1, T 2, T’ 4} are schedulable then there are enough time to end T 4 § increase T 4 ’s priority by increasing period at T 3 Ø can be done only if T 3 : s relative deadline can be larger than the original period Ø T 3 will be 2 tasks T’ 3 and T’’ 3 with period 410 (2 x 210) and c’ 3 = c’’ 3 = 80, a’ 3 = a’’ 3 = 40 Ø tasks T’ 3 och T’’ 3 must be scheduled in such a way they start at T 3=210 Ø if {T 1, T 2, T’ 3, T’’ 3, T 4} are schedulable, we have solved the problem Real-Time System Rate Monotonic Analysis 28

Transient overloading § In general case: 1. 2. 3. 4. § C = set

Transient overloading § In general case: 1. 2. 3. 4. § C = set of critical tasks NC = set of not-critical tasks Pc, max Pnc, min C is schedulable under WCET Procedure: § move those tasks in NC for which P Pc, max to C Ø if C is schedulable under WCET, the system can be scheduled § § § make period for not critical tasks in C larger so that C will be schedulable make period for critical tasks smaller and move not critical tasks with larger period to NC continue until points 1 -4 are satisfied Real-Time System Rate Monotonic Analysis 29

Bad points of ”classic” RMA § § § It requires preemptive scheduler blocking can

Bad points of ”classic” RMA § § § It requires preemptive scheduler blocking can stop the system aperiodic activities must be ”normalized” tasks which have jitter must be specially handled RMA can’t analyze multiprocessor systems Real-Time System Rate Monotonic Analysis 30

Blocking § If two tasks share the same resource, those tasks are dependent §

Blocking § If two tasks share the same resource, those tasks are dependent § Resources are serially and mutually exclusive used § Shared resources are often implemented using semaphores (mutex): § 2 operations Øget Ørelease § Blocking causes two problems: § priority inversion § deadlocks Real-Time System Rate Monotonic Analysis 31

Priority inversion § Priority inversion happens when a task with a lower priority blocks

Priority inversion § Priority inversion happens when a task with a lower priority blocks a task with a higher priority § e. g. Mars Rover was lost because of priority inversion R reserved T 1 T 2 Release R Terminates Allocates R Release R Interrupt Terminates Blocking time T 3 Interrupt Try to allocate R Real-Time System Interrupt and allocates R Rate Monotonic Analysis 32

Deadlock § Deadlock means that there are circular resource allocation: § T 1 allocates

Deadlock § Deadlock means that there are circular resource allocation: § T 1 allocates R 1 § T 2 interrupt T 1 § T 2 allocates R 2 § T 2 try to allocate R 1 but blocks T 1 will be run § T 1 try to allocate R 2 but blocks § Both tasks are now blocked Ödeadlock Real-Time System Rate Monotonic Analysis 33

Deadlock § Deadlocks are always design faults § Deadlocks can be avoided by §

Deadlock § Deadlocks are always design faults § Deadlocks can be avoided by § Special resource allocation algorithms § deadlock-detection algoritms § static analysis of the system ØResource allocation graphs ØMatrix method § Deadlocks will be discussed more thoroughly with parallel programming Real-Time System Rate Monotonic Analysis 34

Priority inversion: control of blocking time § It is difficult to avoid priority inversion

Priority inversion: control of blocking time § It is difficult to avoid priority inversion when blocking happens § Scheduling using fixed priorities produces unlimited blocking time § 3 algorithms for minimization of blocking time: § PIP: Priority inheritance § PCP: Prioirity ceiling § HL: Highest locker Real-Time System Rate Monotonic Analysis 35

Priority Inheritance § 3 rules: 1. Blocked task inherits a temporary priority from the

Priority Inheritance § 3 rules: 1. Blocked task inherits a temporary priority from the blocking task with a higher priority (priorityinheritance rule) 2. Task can lock a resource only if no other task has locked the resource. Task blocks until resources are released, after which task will continue running on its original priority (allocation rule) 3. Inheritance is transitive: § § T 1 blocks T 2, and T 2 blocks T 3 T 1 inherits T 3’s priority Real-Time System Rate Monotonic Analysis 36

Priority inheritance In the example Alowest priority Chighest priority Real-Time System Rate Monotonic Analysis

Priority inheritance In the example Alowest priority Chighest priority Real-Time System Rate Monotonic Analysis 37

Priority inheritance § Blocking time will be now shorter § Maximum blocking time for

Priority inheritance § Blocking time will be now shorter § Maximum blocking time for a task § Length of min(m, n) critical section § m = number of critical sections in application § n = number of tasks with higher priority Ø ”chain blocking” Ø PIP can’t prevent deadlock in all cases Ø priority ceiling algorithm can prevent deadlock and reduce the blocking time Real-Time System Rate Monotonic Analysis 38

Priority Inheritance Real-Time System Rate Monotonic Analysis 39

Priority Inheritance Real-Time System Rate Monotonic Analysis 39

Priority Ceiling 1. Every resource has the highest priority level (”ceiling”): § 2. 3.

Priority Ceiling 1. Every resource has the highest priority level (”ceiling”): § 2. 3. Highest ceiling value (currently used) is stored in a system variable called system ceiling A task can lock or release a resource if § § 4. 5. 6. Highest priority level of task which can lock (or require) the resource It already has locked a resource which has ceiling= system ceiling, or Task’s priority is higher than system ceiling A task blocks until resource will be available and system ceiling variable decrements Blocking task inherits priority from that blocking task which has highest priority Inheritance is transitive Real-Time System Rate Monotonic Analysis 40

Priority Ceiling R 1 ceiling = Prio B R 2 ceiling = Prio C

Priority Ceiling R 1 ceiling = Prio B R 2 ceiling = Prio C system ceiling = R 1 ceiling Real-Time System Rate Monotonic Analysis 41

Priority Ceiling § blocking time for c is now 0 § no ”chain blocking”

Priority Ceiling § blocking time for c is now 0 § no ”chain blocking” possible deadlock not possible in any cases § Complicated implementation Real-Time System Rate Monotonic Analysis 42

Highest locker 1. Every resource has highest priority level (”ceiling”): highest priority of a

Highest locker 1. Every resource has highest priority level (”ceiling”): highest priority of a task which can lock the resource 2. Task can lock or release resource and inherit resources ceiling + 1 as its new priority level § § § Simpler than PCP to implement In practice same properties than PCP ”best” alternative Real-Time System Rate Monotonic Analysis 43

Highest Locker Real-Time System Rate Monotonic Analysis 44

Highest Locker Real-Time System Rate Monotonic Analysis 44

Cost of implementation § PIP protocol § Task generates a context-switch when it blocks

Cost of implementation § PIP protocol § Task generates a context-switch when it blocks § Task generates a context-switch when it becomes executable § Scheduler must keep one queue for semaphores of tasks ordered by priorities § Every time new task needs a semaphore, scheduler must adjust tasks priority to the resource owner’s priority ØOwner (task) must possible inherit the priority § Every times resource is released, disinheritance procedure is executed Real-Time System Rate Monotonic Analysis 45

Costs of implementation § PIWG ( Performance Issues Working Group) has developed benchmarks for

Costs of implementation § PIWG ( Performance Issues Working Group) has developed benchmarks for comparing scheduling algorithms Test Description Fixed-Priority tasking PIP Tasking PIP Overhead T 0001 a call without parameters 28, 5 s 30, 9 s +8, 42% T 0004 T 0001 with selective wait for two calls 40, 5 s 45, 2 s +11, 60% T 0006 T 0004 with 10 tasks 46. 7 s 54, 5 s +16, 49% Real-Time System Rate Monotonic Analysis 46

Cost of implementation § Note: § If the protocol is not in operating system,

Cost of implementation § Note: § If the protocol is not in operating system, it must not be implemented by itself. (application level=>huge overhead) § ”No silver bullet” ØScheduling protocol can only minimize the possibility of blocking ØBlocking must be prevented by improved design Real-Time System Rate Monotonic Analysis 47

Similarities of scheduling protocols Protocol or policy Decrements blocking time limited blocking time Prevents

Similarities of scheduling protocols Protocol or policy Decrements blocking time limited blocking time Prevents deadlocks POSIX implementation Fixed-Priority No No No SCHED_FIFO scheduling policy PIP Yes No No PRIO_INHERIT synchronization protocol for mutex Priority Ceiling Yes Yes PRIO_PROTECT synchronization protocol for mutex Real-Time System Rate Monotonic Analysis 48

Algorithms in commercial RTOS § Priority inheritance § § Wind. River Tornado/Vx. Works Lynx.

Algorithms in commercial RTOS § Priority inheritance § § Wind. River Tornado/Vx. Works Lynx. Os OSE e. COS § Priority Ceiling § OS-9 § p. SOS+ Real-Time System Rate Monotonic Analysis 49

Pushthrough blocking § Task which doesn’t use resource can be still blocked by a

Pushthrough blocking § Task which doesn’t use resource can be still blocked by a task with lower priority § Task with lower priority has temporarily inherited higher priority Task priority Use R under (ms) Locking T 1 3 30 0 T 2 2 - 30 T 3 1 10 30 Real-Time System § T 1 can temporarily run with T 3’s priority § T 2 is blocked even if T 1 and T 2 do not use the resource R Rate Monotonic Analysis 50

Calculation of blocking time 1. calculate pushthrough blocking 2. calculate direct blocking § PCP

Calculation of blocking time 1. calculate pushthrough blocking 2. calculate direct blocking § PCP or HL Ø blocking time for a task = length of the longest critical section which the task participates § PIP Ø Blocking time = length of min(n, m) critical section 3. blocking = max(pushtrough blocking, direct blocking) 4. Task with the lowest priority has no blocking Real-Time System Rate Monotonic Analysis 51

Schedulability: RMA 3 § RMA 1 and RMA 2 can now modified in such

Schedulability: RMA 3 § RMA 1 and RMA 2 can now modified in such a way that they take note the blocking task § Unit of n tasks can be scheduled using RMA if 1 ci Bi c 1 c 2 "i, 1 <=i� <=� n, + +. . . + + �U (i ) = i( 2 i - 1) T 1 T 2 Ti Ti § where Bi is the maximum blocking for Ti § Every prioritised smaller unit of tasks must be schedulable! Real-Time System Rate Monotonic Analysis 52

Schedulability: RMA 4 Real-Time System Rate Monotonic Analysis 53

Schedulability: RMA 4 Real-Time System Rate Monotonic Analysis 53

Example § Take the following application profile with PCP scheduling Task ci (ms) Ti

Example § Take the following application profile with PCP scheduling Task ci (ms) Ti (ms) Uses R (ms) T 1 5 10 1 T 2 8 25 0 T 3 9 60 2 § From the table we get the following data Task ci (ms) Ti (ms) ci /Ti priority Usesr R (ms) Blocking Bi/Ti T 1 5 10 0, 5 2 1 2 0, 2 T 2 8 25 0, 32 1 0 2 0, 08 T 3 9 60 0, 15 0 2 0 0, 00 Real-Time System Rate Monotonic Analysis 54

Example § RMA 4: § i = 1 k = 1 l = 1:

Example § RMA 4: § i = 1 k = 1 l = 1: Ø c 1 + B 1 T 1: true T 1 is schedulable § i = 2 k = 1 l = 1 to 2: Ø c 1 + c 2 + B 2 T 1: false Ø 2 c 1 + c 2 + B 2 2 T 1: true T 2 is schedulable § i = 3 k = 1 l = 1 to 6: Ø c 1 + c 2 + c 3 + B 3 T 1: false Ø 2 c 1 + c 2 + c 3 + B 3 2 T 1: false Ø 3 c 1 + 2 c 2 + c 3 + B 3 3 T 1: false Ø 4 c 1 + 2 c 2 + c 3 + B 3 4 T 1: false Ø 5 c 1 + 2 c 2 + c 3 + B 3 5 T 1: false Ø 6 c 1 + 3 c 2 + c 3 + B 3 6 T 1: false § i = 3 k = 2 l = 1 to 2: Ø 3 c 1 + c 2 + c 3 + B 3 T 2: false Ø 5 c 1 + c 2 + c 3 + B 3 2 T 2: true T 3 is schedulable Real-Time System Rate Monotonic Analysis 55

PCP: Proof § Lemma 1: Task T 1 can be blocked by a task

PCP: Proof § Lemma 1: Task T 1 can be blocked by a task T 2 with lower priority only if T 2 is in critical section when T 1 starts § Lemma 2: Task T 1 can be blocked by a task T 2 with lower priority only if T 1 has a priority which is less or the same than the highest priority of all semaphores locked by tasks that have lower priority Real-Time System Rate Monotonic Analysis 56

PCP: Proof § Lemma 3: Suppose that T 2 is in critical section S

PCP: Proof § Lemma 3: Suppose that T 2 is in critical section S 2, and it is interrupted by task T 1 with higher priority, which afterwards enters critical section S 1. T 2 can not inherit priority which is higher or the same to T 1 before T 1 has been ended. § Lemma 4: PCP prevents transitive blocking § Theorem P 1: PCP prevents deadlocks Real-Time System Rate Monotonic Analysis 57

PCP: Proof § Suppose that T 1 has a higher priority than T 2.

PCP: Proof § Suppose that T 1 has a higher priority than T 2. Let B 1, 2 be a unit of critical sections where T 2 can block T 1. Let then b 1, 2 be the critical section which has the longest running time. § Lemma 5: T 1 can be blocked by the longest running time of b 1, 2 § Let Bi be a unit of critical sections for tasks with lower priority than Ti, and let bi be a critical section in Bi with longest running time. § Theorem P 2: Task Ti can be blocked only by a task with lower priority and at most the length of bi Real-Time System Rate Monotonic Analysis 58

Random deadlines § Given for RMA 1 -4: § deadline = period § Happens

Random deadlines § Given for RMA 1 -4: § deadline = period § Happens not very often § An event must be handled proper time before it happens next time § Example: Ø Value of hardware register is updated every 20 ms Ø Value is correct at least the first 10 ms § An event can be also handled after it will be reached second time § Example: Ø UART chip has a FIFO buffer which can store 2 bytes Ø Time between two characters is n ms Ø deadline is 2 n ms Real-Time System Rate Monotonic Analysis 59

Random deadlines § 3 cases 1. Algorithms for calculation of response time in case

Random deadlines § 3 cases 1. Algorithms for calculation of response time in case of deadline < period 2. expansion to the case deadline > period with blocking 3. expansion to dynamic priorities (not in this course) Real-Time System Rate Monotonic Analysis 60

Deadline Period § Algorithm for calculation of the longest possible response time § §

Deadline Period § Algorithm for calculation of the longest possible response time § § ”completion time test” 4 requirements: 1. 2. 3. 4. All tasks are periodic No blocking deadline period Priorities have been allocated by RMA § e. g. shortest period has the highest priority Real-Time System Rate Monotonic Analysis 61

Deadline Period § Idea: § Calculate successive approximations for responce times until all tasks

Deadline Period § Idea: § Calculate successive approximations for responce times until all tasks are in the same phase § in RMA 2 we know that if a task meets its first deadline then all tasks are in the phase, and the task will meet its following deadlines § If we can show that tasks responce time for the first case is shorter than the first deadline, then the task will clear its all following deadlines Real-Time System Rate Monotonic Analysis 62

Deadline Period § Analyse a task Ti (tasks T 1. . . Ti-1 have

Deadline Period § Analyse a task Ti (tasks T 1. . . Ti-1 have higher priorities) § First estimate of the response time is: § Estimate can be lower than the real response time, in that case tasks with shorter period can be executed more times Real-Time System Rate Monotonic Analysis 63

Deadline Period § Correct version § An is the worst case of response time

Deadline Period § Correct version § An is the worst case of response time of Ti to its event Real-Time System Rate Monotonic Analysis 64

Example Task Ti (ms) ci (ms) Priority Blocking Deadline T 1 100 40 3

Example Task Ti (ms) ci (ms) Priority Blocking Deadline T 1 100 40 3 0 100 T 2 150 50 2 0 150 T 3 400 70 1 0 270 § Total utilization is 40/100+50/150+70/400 = 91% § Is T 3 schedulable? Real-Time System Rate Monotonic Analysis 65

Example T 3 is not schedulable 290>270 Real-Time System Rate Monotonic Analysis 66

Example T 3 is not schedulable 290>270 Real-Time System Rate Monotonic Analysis 66

Busy period § § Let Si = {T 1, . . . , Ti},

Busy period § § Let Si = {T 1, . . . , Ti}, where T 1 has the highest and Ti lowest priority busy period for priority i: § interval [a, b] such that: Ø Ø § b>a only tasks from Si which executes under [a, b] processor is utilized the whole time under [a, b] processor runs no task from Si just before a, and just after b Time that the processor runs a job with priority i Real-Time System Rate Monotonic Analysis 67

Busy period T 3 T 1 T 2 T 3 T 4 T 5

Busy period T 3 T 1 T 2 T 3 T 4 T 5 Level 1 busy period Level 2 busy period Level 3 busy period Level 4 busy period Level 5 busy period § Theorem: Task Ti has the longest response time under the busy period for priority in which initializes with phase I 1=. . . =Ii=0 Real-Time System Rate Monotonic Analysis 68

Random deadlines with blocking § 3 requirements: 1. Periodic tasks 2. Effective utilization <

Random deadlines with blocking § 3 requirements: 1. Periodic tasks 2. Effective utilization < 100% 3. Priorities set by RM § Expansion of previous iterative algorithms § If response time is before deadline but after period, busy period is not ended: tasks need more resources § If responce time is before deadline and before period, the busy period is over Real-Time System Rate Monotonic Analysis 69

Random deadlines with blocking § First estimate: § Iteration: § We must iterate over

Random deadlines with blocking § First estimate: § Iteration: § We must iterate over k number of iterations of the job Real-Time System Rate Monotonic Analysis 70

Compute approximation a 0 of a response date for job k of task Ti

Compute approximation a 0 of a response date for job k of task Ti Next job k=k+1 n=0 Compute approximation an+1 of a response date for job k of task Ti an+1= an no Approximation is not stabilized n=n+1 Compute response time Ei, k for job k of task Ti no End of busy period Ei, 1 Ei, 2 Ei, 3 Ei, k Ti . . . yes Determine worst case of response time for task Ti Real-Time System Rate Monotonic Analysis 71

Example Task Ti (ms) ci (ms) priority Blocking Deadline T 1 100 30 4

Example Task Ti (ms) ci (ms) priority Blocking Deadline T 1 100 30 4 0 100 T 2 150 40 3 0 150 T 3 250 50 2 40 300 T 4 1000 1 0 300 § Total utilization 30/100+40/150+50/250+100/1000= 87% § T 3 has maximum blocking of 40 ms § is T 3 schedulable? Real-Time System Rate Monotonic Analysis 72

Example Real-Time System Rate Monotonic Analysis 73

Example Real-Time System Rate Monotonic Analysis 73

Example Real-Time System Rate Monotonic Analysis 74

Example Real-Time System Rate Monotonic Analysis 74

Changing priorities § Not in this course. . . § The reference material §

Changing priorities § Not in this course. . . § The reference material § M. H. Klein, J. P Lehczky, R. Rajkumar, ”Rate. Monotonic Analysis for Real-Time Industrial Computing”, IEEE Computer, vol 27, no 1, January 1994, pp 24 -33. Real-Time System Rate Monotonic Analysis 75

Deadline Monotonic Priority Assignment § RM: § Shortest period gets the highest priority §

Deadline Monotonic Priority Assignment § RM: § Shortest period gets the highest priority § DM: § Shortest deadline gets the highest priority § DM gives higher utilization § Get first the analysis using RM, allocate then priorities using DM Real-Time System Rate Monotonic Analysis 76

Dynamic scheduling § Priorities are calculated at run time § Earliest deadline first (EDF):

Dynamic scheduling § Priorities are calculated at run time § Earliest deadline first (EDF): § Task with shortest time to the deadline executed first § It is always possible to transform timing plan which meets deadlines to the timing plan under EDF ØEDF is an optimal scheduling algorithm § It is not simple to show that the system is schedulable using EDF § RMA is enough in practice § tasks need not to be periodic! Real-Time System Rate Monotonic Analysis 77

EDF: Example § § § Task Start time ci absolute deadline T 1 0

EDF: Example § § § Task Start time ci absolute deadline T 1 0 10 30 T 2 4 3 10 T 3 5 10 25 When t=0 can only T 1 run. When t=4 has T 2 higher priority because d 2 < d 1 When t=5 has T 2 higher priority than T 3 When t=7 stops T 2 and T 3 has higher priority When t=17 stops T 3 and T 1 executes Real-Time System Rate Monotonic Analysis 78

EDF: test of schedulability § In general case, we must simulate the system to

EDF: test of schedulability § In general case, we must simulate the system to show that it is schedulable § finity criterion gives limits to the simulation § Let h. T(t) be the sum of running times of those tasks in unit T which have an absolute deadline Real-Time System Rate Monotonic Analysis 79

Aperiodic activities § § In practice not every event is periodic Aperiodic activities are

Aperiodic activities § § In practice not every event is periodic Aperiodic activities are often I/O activities Ø Connected to the interrupt lines of the CPU Ø Processors’ interrupt has always higher priority than the scheduler of the operating system § How could the aperiodic events be connected that the system will be schedulable? Real-Time System Rate Monotonic Analysis 80

Aperiodic activities § Look 5 different implementation models: 1. Interrupt handled at hardware priority

Aperiodic activities § Look 5 different implementation models: 1. Interrupt handled at hardware priority level 2. Cyclic polling (handled at the os-schedulers priority level) 3. Combination of 1 and 2 (deferred aperiodic handling) 4. Interrupt handled partially at hardware level and partially at OS level with a deferred server 5. Interrupt handled partially at hardware level and partially OS level with a sporadic server Real-Time System Rate Monotonic Analysis 81

Hardware handling § Interrupt handled wholy by interrupt service routine (ISR) Benefits §Simplementation §easy

Hardware handling § Interrupt handled wholy by interrupt service routine (ISR) Benefits §Simplementation §easy to analyse with RMA §Minimal overhead Problems §there maybe starving on OS level §RMA: calculate ”pseudoperiod” for ISR based on events incoming time §use in order to handle event more rapidly §it must be always shown with RMA that applications stay schedulable even with storm of events Real-Time System Rate Monotonic Analysis 82

Cyclic polling § One task allocate for handling of events § Hardware must buffer

Cyclic polling § One task allocate for handling of events § Hardware must buffer § Requirements: § Only one event should happens between two cycles § Event must be handled before its deadline ØIf polling task is not executed with the highest priority, its period should be highest half of the events deadline Event 0 1 period n+1 5 D Real-Time System Processering 10 Rate Monotonic Analysis 83

Cyclic polling Benefits §Simplementation §Full control of the overhead §no hardware processing Problems §Overhead

Cyclic polling Benefits §Simplementation §Full control of the overhead §no hardware processing Problems §Overhead (unnecessary polling) §possibly makes RMA more complicated §RMA: Calculate a period for the polling task. Execution time will be the time for handling the event. Suppose that an event is handled at every cycle §Used even if events happen seldom §it should always be shown with RMA that applications schedulability is not disturbed by pollings overhead Real-Time System Rate Monotonic Analysis 84

Delayed handling § Partition handling to two parts: § ISR: handle those tasks that

Delayed handling § Partition handling to two parts: § ISR: handle those tasks that must be handled immediately: Ø Reading of hardware registers Ø. . § ”deferred handler” (DH) will be activated that handles the rest of task Benefits §small amount of hardware processing §DH can handle many different events Problems §delayed handler is an aperiodic task §RMA: Calculate a pseudoperiod for ISR. Calculate a pseudoperiod for DH: n based of ISR’s pseudoperiod The immediate/deferred scheme is a better approach than the full immediate handing scheme(risk of monopolizing the processor) or the cyclic poll scheme (high overhead) Real-Time System Rate Monotonic Analysis 85

Deferred Server § Delayed handling is still aperiodic § Idea: make DH periodic §

Deferred Server § Delayed handling is still aperiodic § Idea: make DH periodic § Server process § period § for prevention that server takes all processing capacity, server under period is given limited execution capacity § After server goes idle, the consumed processor capacity can be restored (replenishment period) § deferred server restores its processing capacity at the beginning of period Real-Time System Rate Monotonic Analysis 86

Deferred server Event A 0 Event B 4 5 Event C 8 Event D

Deferred server Event A 0 Event B 4 5 Event C 8 Event D 10 12 15 § execution capacity 1 (one event/period) § period 4 § server is redo when t=0, but runs first when t=3 e. g. phase = 3 § RMA analysis needs that every task should be executable at the beginning of the cycle Real-Time System Rate Monotonic Analysis 87

Sporadic server § sporadic server restores its capacity first after capacity has been used

Sporadic server § sporadic server restores its capacity first after capacity has been used § execution capacity 1 (one event/period) § period 4 § so that A (t=3) use the whole processing capacity, can B be processed first at t = 3+4=7 Event A 0 3 Event B 5 Event C 7 Real-Time System Event D 10 15 11 Rate Monotonic Analysis 88

Sporadic server § sporadic server can be handled as a periodic task with variable

Sporadic server § sporadic server can be handled as a periodic task with variable phase Event A 0 phase=1 Event B 3 No event to handle 5 7 Event C 10 11 phase=2 Real-Time System Event D 15 Rate Monotonic Analysis 89

Sporadic Server § Implementation: § Operating system: ØPOSIX 1003. 1 d defines an interface

Sporadic Server § Implementation: § Operating system: ØPOSIX 1003. 1 d defines an interface for sporadic server scheduling § By own coding: Øcomplicated Real-Time System Rate Monotonic Analysis 90

Sporadic server § Calculation of period: § hard deadline: Ø minimum interarrival time/2 Ø

Sporadic server § Calculation of period: § hard deadline: Ø minimum interarrival time/2 Ø event deadline/2 § bursty hard deadline: Ø server period = 1/event density § soft deadine: Ø M/D/1 queue-analys Ø W = average response time Ø I = average interarrival time Ø I in general Ø then server runs with the highest priority (e = processing time for an event) Real-Time System Rate Monotonic Analysis 91

Sporadic server § Control of schedulability Criterions Analysis technique Soft deadline schedulability of soft

Sporadic server § Control of schedulability Criterions Analysis technique Soft deadline schedulability of soft deadlines can’t be quarantied. M/D/1 technique gives approximate responce times Hard deadline, deadline=period, no blocking RMA 1 and RMA 2 Hard deadline, deadline=period, blocking RMA 3 and RMA 4 Hard deadline, deadline before or after period, blocking Random deadlines Real-Time System Rate Monotonic Analysis 92

Example Event Description Processering (ms) Period (ms) Deadline (ms) e 1 periodic 5 30

Example Event Description Processering (ms) Period (ms) Deadline (ms) e 1 periodic 5 30 25 e 2 hard deadline: §sporadic incoming time, maximal rate: 23 evens in 150 ms §direct processering: 0, 1 ms §delayable processering: 0, 9 ms §a hardware queue saves last 23 events 1 - - e 3 periodic 58 200 e 4 periodic 127 600 § Is this system schedulable? § Depends on the implementation Real-Time System Rate Monotonic Analysis 93

Summary § § RMA 1, 2 Dealing with blocking. . RMA 3, 4 Arbitrary

Summary § § RMA 1, 2 Dealing with blocking. . RMA 3, 4 Arbitrary ´deadline Aperodic tasks Real-Time System Rate Monotonic Analysis 94