Scheduling in Real-Time Systems

Scheduling in Real-Time Systems
Goal To understand the role that scheduling and schedulability analysis plays in predicting that real-time applications meet their deadlines Slides due to Burns, Welllings and Bradley

References Burns & Wellings Burns Liu
“Real-time Systems and their Languages”4th ed chapter 11 pp Addison Wesley, 2009 Burns “Scheduling hard real-time systems: a review” Software Eng. J, May 1991 Liu “Real-Time Systems” Prentice Hall, 2000 Ref 1 - standard text for course Ref 2 - a very good review of scheduling algorithms (essential to read) Ref 3 - useful description of how ceiling protocol works and presents notation that can be used to help trace behaviour based in Z Ref 4 - describes a tool for modelling performance also contains examples of algorithms

What is the problem? Real-time systems need to be accurate, fast and predictable Need to be able to provide guarantees on the temporal behaviour of the system

Basic concepts : Tasks A unit of execution
will generally have the following properties Ci the worst case execution time Ti the period Di the deadline by which the task must complete execution Oi an offset or release time

Visualisation T D O C t0 t0 + D t0 + T

Basic Concept :Deadlines
Time by which task must complete May be Absolute Relative ( mostly in these notes) Missed deadline = error condition Hard Deadlines missed  damage Soft Deadlines missed  no compromising of system integrity Hard real-time systems have crucial deadlines where damage is catastrophic An inherent characteristic of real-time systems timing information known as deadlines Essential for correct running that these deadlines be met Types of deadlines range from Hard to Soft relates to strength of error condition arising from missed deadline. Hard real-time systems have crucial deadlines damage catastrophic may increase with time Mention “Safety Critical”

Hard Soft Safety Critical start deadline u t i l y time time u t i l y
g e time start deadline

Basic Concepts: Periodic Tasks
Execute on a regular basis Characterised by their period their deadline (often taken to equal period) execution time per period Execution time known in terms of average requirement worst case e.g. task execute every second, using on average 100msec worst case 300msec System timing requirements means we have task deadlines Meeting deadlines mean need task scheduling Must look at behaviour of tasks to determine nature of the scheduling algorithm. One type of task is Periodic Period say once per 5secs Deadline may be specified exactly but more common to be related to period CPU time is needed - may be working in terms of average or worst case. Note talking real-time so must be careful about which used since must meet deadlines. Periodic generally straight forward.

Basic Concepts : Aperiodic Tasks
Activation a random event, usually triggered by external event Have timing constraints e.g.. having started must complete within predefined time Often associated with critical events in environment so deadlines important Since random can't do worst case analysis implies no hard deadlines Problem for scheduling Random events related to external environment Because of the timing constraints must try and schedule, the triggering event is often crucial to running of systems. Because of randomness can't do worst case. In general assumed to follow a Poisson distribution, this allows for bursty arrivals without precluding a concentration of aperiodic activity

Basic Concepts : Sporadic Tasks
If a minimum period between any two aperiodic events can be defined the tasks involved are said to be Sporadic Can do worst case analysis Can have hard deadlines To help with necessary analysis a minimum period between any two aperiodic events is defined. This permits a type of periodicity to be identified. Hence can have worst case analysis sand hard deadlines In following work on performance and schedulability will consider periodic and sporadic tasks. Ideal to design out aperiodic - MAY NOT BE POSSIBLE!

Basic Concepts: Preemption
The execution of a task can be suspended Any resource it is using may be released Resource = cpu no problem Resource = printer problem

Basic Concepts: Response time / Critical Instant
The difference between a task’s completion time and its release time (In many examples the release time is taken as 0 so the reponse time is the completion time) Critical Instant The instant at which a release of that task will have the largest response time

The problem Suppose we have the following simple system, (assume the deadline and period are equal for all tasks, preemption in allowed) Task T C a b c How can you guarantee that you can produce a schedule that will always work?

Or these Example 3 Task T C
b c Example 3 Task T C a b c Try and draw simple graphs to see what happens with each

Summary of Requirements for Real-Time Scheduling Scheme
Deadlines need to be met Hard /Soft Utility / Damage tasks Periodic Aperiodic Sporadic Timing Period Deadline CPU time These are basic considerations in devising a scheduling system We need scheduling algorithms that enable the deadline requirements of the system to be guaranteed can accommodate the different types of tasks Basic data we have to work with is the period and CPU requirement

Scheduling In general, a scheduling scheme provides two features:
An algorithm for ordering the use of system resources (in particular the CPUs) A means of predicting the worst-case behaviour of the system when the scheduling algorithm is applied The prediction can then be used to confirm the temporal requirements of the application

Simple task Model The application is assumed to consist of a fixed set of tasks All tasks are periodic, with known periods The tasks are completely independent of each other All system's overheads, context-switching times and so on are ignored (i.e, assumed to have zero cost) All tasks have a deadline equal to their period (that is, each task must complete before it is next released) All tasks have a fixed worst-case execution time

Task states Running Runnable
Suspended waiting for a timing event (periodic tasks) Suspended waiting for a non-timing event (sporadic tasks)

Task-Based Scheduling
Fixed-Priority Scheduling (FPS) Earliest Deadline First (EDF) Value Based Scheduling (VBS)

Scheduling Characteristics
We need to be able to test shedules A test is said to be Sufficient if a positive outcome guarantees that all deadlines will always be met Necessary if failure of the test will lead to a missed deadline at some point in the system execution A necessary and sufficient test is exact and in some sense optimal

Scheduling tests are generally applied to worst case situations
A scheduling test is said to be sustainable if it correctly predicts that a schedulable system remains schedulable when its operating parameters “improve” e.g. Increasing deadlines

Fixed-Priority Scheduling (FPS)
This is the most widely used approach Each task has a fixed, static, priority which is computer pre-run-time The runnable tasks are executed in the order determined by their priority In real-time systems, the “priority” of a task is derived from its temporal requirements, not its importance to the correct functioning of the system or its integrity

Preemption and Non-preemption
With priority-based scheduling, a high-priority task may be released during the execution of a lower priority one In a preemptive scheme, there will be an immediate switch to the higher-priority task With non-preemption, the lower-priority task will be allowed to complete before the other executes Preemptive schemes enable higher-priority tasks to be more reactive, and hence they are preferred

Preemption and Non-preemption, cont
Alternative strategies allow a lower priority task to continue to execute for a bounded time These schemes are known as deferred preemption or cooperative dispatching

Priority Pre-emption Example
Context switch B A A t0 t1 time Priority(A) < Priority(B) B arrives at time t0 A is pre-empted B completes at t1 For real-time systems the context switching time must be fast Talk through example Context switching:- when task suspended its current context must be saved, e.g. save registers, pc, update control block when task assigned CPU context must be restored context switching represents an overhead that must be minimised for real-time systems.

Priority Pre-emptive Scheduling
Most common real-time scheduling algorithm Operation each task assigned a priority ready queue ordered by priority highest priority task assigned CPU keeps CPU until blocked or pre-empted does not use time slicing How are priorities assigned? How sure of meeting deadlines? Fair allocation of resources not a prime concern for RT systems. time critical tasks must make deadlines so need some priority system. describe operation in general Address question on priority assignment in next set of slides Also show analysis to backup claims about meeting deadlines

Rate Monotonic Priority Assignment
Each task is assigned a (unique) priority based on its period; the shorter the period, the higher the priority i.e, for two tasks i and j, This assignment is optimal in the sense that if any task set can be scheduled (using pre-emptive priority-based scheduling) with a fixed-priority assignment scheme, then the given task set can also be scheduled with a rate monotonic assignment scheme Note, priority 1 is the lowest (least) priority

Example Priority Assignment
Task Pd, T C Priority, P a b c d e

Task Utilisation Ui = Ci / Ti
The utilisation of a task i is defined as Ui = Ci / Ti Calculate the utilisation for each task on the previous slide

Utilisation Bound Theorem
Theorem (Liu and Layland) A set of n independent tasks, scheduled by the rate monotonic algorithm, will always meet its deadline, for all phasings, if This is an important result. Ci & Ti represent the CPU time per period and the period respectively. U(n) is the utilisation function The upper bound U(n) converges to 69% as the value of n tends to infinity Problem for students: calculate values for the upper bounds for smaller numbers of tasks U(3) = 77.9% Worst case approximation

Notes on Utilisation-Based Analysis
For D=T task sets only The test is : sufficient not necessary What does this mean?

Utilisation Bounds N Utilisation bound 1 100.0% 2 82.8% 3 78.0%
% % % % % % Approaches 69.3% asymptotically

Task Set A The combined utilization is 0.82 (or 82%)
Task T C P U a b c The combined utilization is 0.82 (or 82%) This is above the threshold for three tasks (0.78) and, hence, this task set fails the utilization test

Time-line for task Set A
task Release Time task Completion Time Deadline Met Deadline Missed Executing Preempted a b c 10 20 30 40 50 60 Time

Gantt Chart for task Set A
b a c b 10 20 30 40 50 Time

Task Set B The combined utilization is 0.775
Task T C P U a b c The combined utilization is 0.775 This is below the threshold for three tasks (0.78) and, hence, this task set will meet all its deadlines

Task Set C The combined utilization is 1.0
Task T C P U a b c The combined utilization is 1.0 This is above the threshold for three tasks (0.78) but the task set will meet all its deadlines

Time-line for task Set C
b c 10 20 30 40 50 60 70 80 Time

Improved Utilisation Tests #1
We can group tasks into families which have periods that are multiples of a common value e.g. 8,16,64 N now stands for the number of families

Consider task set B Have 2 families {a,b} and {c} So bound for system is now U(2) = 0.828 utilisation for B is still 0.775 Modify set B so task c has period 14 Utilisation for set B is now 0.81 Fails on basic test Okay on this one What happens with set C?

New test has the form Consider set B but with period for a set to 76 1.421 * * 1.25 = <2 So schedulable Draw time line for modified set B

Criticism of Utilisation-based Tests
Not exact Not general It is pessimistic The test is said to be sufficient but not necessary

Response Time Analysis
More General test Predict worst case response time for each task Make sure the response time is less that the deadline For the highest priority task the response time, R, is just its own computation time Other tasks will suffer interference from higher priority tasks

Response-Time Analysis
Here task i's worst-case response time, Ri, is calculated first and then checked (trivially) with its deadline Where Ii is the interference from higher priority tasks

Calculating Ri Maximum interference occurs when all higher priority tasks released at same time as task i. During R, each higher priority task j will execute a number of times: The ceiling function   gives the smallest integer greater than the fractional number on which it acts. So the ceiling of 1/3 is 1, 6/5 is 2, 6/3 is 2. So if R = 15 and T =6 there are 3 releases ~ at 0, 6, 12

Calculating Ri Total interference due to task j is :
Total interference due to all higher priority tasks is :

Worst Case Response Times
CPU + Interference due to higher priority tasks Use the formula: Where hp(i) is the set of tasks with priority higher than task i

Completion Time Theorem
For a set of independent periodic tasks, if each task meets its first deadline when all tasks are started at the same time, then the deadlines will be met for any combination of start times If a set of tasks have high utilisation than Utilisation Bound Theorem’s upper bound then can use Completion Time.

Some observations Completion Time Theorem provides an exact determination of whether tasks are schedulable Assumes worst case of all ready at same time Must check end of first period of given task pi end of all periods of higher priority tasks (end of periods called scheduling points) Comment on more accurate analysis but harder to apply It has been shown that ‘all ready at same point’ is worst case. & if a task meets its first deadline under these conditions it will meet all deadlines Assuming rate monotonic priorities all tasks with higher priority than pi will have shorter periods. task pi will use Ci cpu time during its period ti. Other higher priority tasks will execute more often and pre-empt pi.

Response Time Equation
Solve by forming a recurrence relationship: The set of values is monotonically non decreasing When the solution to the equation has been found,

Task Set D Task T C P a b c Task a Task b

A B C 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Revisit: task Set C The combined utilization is 1.0
task Period ComputationTime Priority Response time T C P R a b c The combined utilization is 1.0 This was above the utilization threshold for three tasks (0.78), therefore it failed the test The response time analysis shows that the task set will meet all its deadlines

Exercise Suppose we have the following tasks
A : C = 3, T= 5 B : C = 5, T = 14 C : C = 1, T = 50 Check the schedulability of this set using the Completion Time Theorem RA = 3 RB = 14 Rc = 40

Exercise Suppose we have the following tasks
A : C = 4, T= 10 B : C = 6.1, T = 14 C : C = 1, T = 70 Check the schedulability of this set using the Completion Time Theorem RA = 4 RB = not schdulable Rc = 25.2

Response Time Analysis
Is sufficient and necessary If the task set passes the test they will meet all their deadlines; if they fail the test then, at run-time, a task will miss its deadline (unless the computation time estimations themselves turn out to be pessimistic)

Scenario T=period C=CPU

Rate MonotonicPriority and Utilisation
6 high 1 low total utilisation 0.785 > 0.735 so must do next test

Calculations

Rest of Calculations Rd,i={28,31,32,32} RB,i={37,44,45,45}
You do sums to check! D: Rd,i={28,31,32,32} B: RB,i={37,44,45,45} A: RA,i={41,48,49,49} So set of worst case response times using Rate Monotonic priority assignment is: { (F,1), (E,3), (C,26), (D,32), (B,45), (A,49) } Can schedule

Revised Scenario - Deadlines some Di<Ti
T=period C=CPU D=deadline

Scedulability? Forget deadlines: No problems D<T ? Use Deadlines:
Problems D fails R=32, D=7 A fails R=49, D=30 D<T ?

Deadline Monotonic Priority Assignment
Each task is assigned a (unique) priority based on its deadline; the shorter the deadline, the higher the priority i.e, for two tasks i and j,

Deadline Monotonic Priority
D & F have same deadline priority assignment arbitary In real situation consider physical environment

Calculations

Rest of Calculations Re,i={12,13,13} Rc,i={32,36,39,39}
B: Rb,i={41,48,49,49}

Cont. So set of worst case response times usingDeadline Monotonic priority assignment is: { (D,5), (F,6), (A,11), (E,13), (C,39), (B,49) } Deadlines: { (D,7), (F,7), (A,30), (E,33), (C,50), (B,100) } so okay

task Sets with D < T For D = T, Rate Monotonic priority ordering is optimal For D < T, Deadline Monotonic priority ordering is optimal i.e. if any task set, Q, that is schedulable by priority scheme, W, is also schedulable by DMPO

D < T Example task Set
task Period Deadline ComputationTime Priority Response time T D C P R a b c d

Sporadic tasks Schedule using DMA
Sporadics tasks have a minimum inter-arrival time e.g. may have inter-arrival minimum of 20 ms So can model as periodic with T = 20 But may not arrive so frequently Often used to encapsulate error handling or to respond to a warning May not run often but when does requires short deadline So may require D<T Schedule using DMA

Hard and Soft tasks In many situations the worst-case figures for sporadic tasks are considerably higher than the averages Interrupts often arrive in bursts and an abnormal sensor reading may lead to significant additional computation Measuring schedulability with worst-case figures may lead to very low taskor utilizations being observed in the actual running system

General Guidelines Rule 1 — all tasks should be schedulable using average execution times and average arrival rates Rule 2 — all hard real-time tasks should be schedulable using worst-case execution times and worst-case arrival rates of all tasks (including soft)

A consequent of Rule 1 is that there may be situations in which it is not possible to meet all current deadlines This condition is known as a transient overload Rule 2 ensures that no hard real-time task will miss its deadline If Rule 2 gives rise to unacceptably low utilizations for “normal execution” then action must be taken to reduce the worst-case execution times (or arrival rates)

Dynamic Algorithms Schedules determined at run-time Flexible
overhead Flexible can react to levels of activity beyond that anticipated Appropriate for Hard systems? safety critical implies no unpredictable event Appropriate for soft systems error recovery after missed deadlines may be needed when no worst case upper limit All schedules determined at run time implies run time overhead Yes is flexible But not for hard systems - matter for debate (still subject of research activity!) Okay / important role in systems listed on slide No worst case example : number of planes in an air traffic control area.

Dynamic Priority Algorithms
An important class of scheduling algorithms is the class of dynamic priority algorithms In dynamic priority algorithms, the priority of a task can change during its execution Fixed priority algorithms are a sub-class of the more general class of dynamic priority algorithms: the priority of a task does not change.

Earliest Deadline First (EDF)
The priority of a task (instance) is inversely proportional to its absolute deadline; In other words, the highest priority job is the one with the earliest deadline; If two tasks have the same absolute deadlines, chose one of the two at random (ties can be broken arbitrarily). The priority is dynamic since it changes for different jobs of the same task.

Earliest Deadline First (EDF) Scheduling
The runnable tasks are executed in the order determined by the absolute deadlines of the tasks The next task to run being the one with the shortest (nearest) deadline Although it is usual to know the relative deadlines of each task (e.g. 25ms after release), the absolute deadlines are computed at run time and hence the scheme is described as dynamic End 1st lecture

Utilization-based Test for EDF
A much simpler test Superior to FPS; it can support high utilizations.

Earliest Deadline First
Example

The task set task CPU C Period T A 1 4 B 2 6 3 8

Missed deadline RMA A B C 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
19 20 21 22 23 24 Missed deadline

Ready Queue : { (A,4), (B,6), (C,8) }
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Ready Queue : { (B,6), (C,8) } A B C 1 2 3 4 5 6 7 8 9 10 11 12 13 14
15 16 17 18 19 20 21 22 23 24

Ready Queue : { (C,8) } at time 4 A wakes up so need to reconsider ownership of CPU
B C 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Ready Queue : { (A,8), (C, 8) } Note same deadline choose one task at random; since C has CPU leave it A B C 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Ready Queue : { (A,8), (B,12) } A B C 1 2 3 4 5 6 7 8 9 10 11 12 13 14
15 16 17 18 19 20 21 22 23 24

Ready Queue : { (B,12) } A B C 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Ready Queue : { (A,12), (B,12), (C,16) } A & B have same deadlines as before let B keep CPU
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Ready Queue : { (A,12), (C,16) } A B C 1 2 3 4 5 6 7 8 9 10 11 12 13
14 15 16 17 18 19 20 21 22 23 24

Ready Queue : { (C,16) } A B C 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Ready Queue : {(A,16), (B,18), (C,16) }
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Ready Queue : {(A,16), (B,18)} A B C 1 2 3 4 5 6 7 8 9 10 11 12 13 14
15 16 17 18 19 20 21 22 23 24

Ready Queue : {(B,18)} A B C 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Ready Queue : {(A,20), (B,18), (C,24)}
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Ready Queue : {(A,20), (C,24)} A B C 1 2 3 4 5 6 7 8 9 10 11 12 13 14
15 16 17 18 19 20 21 22 23 24

Ready Queue : {(C,24)} A B C 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Ready Queue : {(B,24), (C,24)} A B C 1 2 3 4 5 6 7 8 9 10 11 12 13 14
15 16 17 18 19 20 21 22 23 24

Ready Queue : {(A,24), (B,24) } A B C 1 2 3 4 5 6 7 8 9 10 11 12 13 14
15 16 17 18 19 20 21 22 23 24

Ready Queue : {(A,24)} A B C 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Ready Queue : {} A B C 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Alternative pattern A B C 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
19 20 21 22 23 24

Exercise Given the following set of tasks draw a graph showing the
behaviour using RMA and then EDF task CPU C Period T A 4 10 B 8 15 2 30

RMA Missed Deadline A B C 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
19 20 21 22 23 24 25 26 27 28 29 30 Missed Deadline

EDF A B C 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Notes EDF is an optimal algorithm, in the sense that if a task set if
schedulable, then it is schedulable by EDF. In fact, if U > 1 no algorithm can succesfully schedule the task set; if U ≤ 1, then the task set is schedulable by EDF (and maybe by other algorithms). In particular, EDF can schedule all task sets that can be scheduled by FP, but not vice versa.

However ... FPS is easier to implement as priorities are static
EDF is dynamic and requires a more complex run-time system which will have higher overhead It is easier to incorporate tasks without deadlines into FPS; giving a task an arbitrary deadline is more artificial

More However ... It is easier to incorporate other factors into the notion of priority than it is into the notion of deadline During overload situations FPS is more predictable; Low priority task miss their deadlines first EDF is unpredictable; a domino effect can occur in which a large number of tasks miss deadlines End 2nd lecture

Exercise Draw graphs showing the execution of the following set of tasks under EDF and RMA task CPU C Period T A 2 5 B 6 7 D 8

Generalization to deadlines different from period
EDF is still optimal when relative deadlines are not equal to the periods. However, the schedulability analysis formula become more complex. If all relative deadlines are less than or equal to the periods, a first trivial (sufficient) test consist in substituting Ti with Di:

Deadlines Different From Period
If all relative deadlines are less than or equal to the periods, a first trivial (sufficient) test consist in substituting Ti with Di:

Scheduling in Real-Time Systems

Similar presentations

Presentation on theme: "Scheduling in Real-Time Systems"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Scheduling in Real-Time Systems

Similar presentations

Presentation on theme: "Scheduling in Real-Time Systems"— Presentation transcript:

Similar presentations

About project

Feedback