Class Module: Real-Time Systems - wmich.edurhardin/ece5150/Liu_PPT.pdfExecution Task A larger piece...

Preview:

Citation preview

Class Module:Real-Time Systems

Sebastian Fischmeistersfischme@ecemail.uwaterloo.ca

Department of Electric and Computer EngineeringUniversity of Waterloo

November 7, 2007

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 1 / 61

Lecture Thesis:

Understand the different notions of real-time.

Be able to speak to communicate with real-time systems people.

Learn a little bit about scheduling

Learn about proofs in scheduling

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 2 / 61

Execution

Task

A larger piece of functionality in your real-time system.

Simple task vs complex task

Job

A unit of work that is scheduled.

A task consists of multiple jobs: GPS reading job, update map job

For simple tasks, the task usually is the job.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 3 / 61

Job Characteristics

tri di

Ji Ji

si fipreempt resume

preemptedφi dly slack

response time

Maximum response time = relative deadline (D)

di = ri + Dj

Phase and offset are similar

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 4 / 61

Tardiness

... specifies how long the job is overdue.

tdi

Ji

response time > dlrel

tardiness

If the job completes at or before the deadline, the tardiness is zero.

Lateness is similar, but also has negative values.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 5 / 61

Hard Real-Time Systems

Characteristics

Missing a deadline is considered a fatal fault.

Tardiness must always be zero!

Applications & Notes

Safety-critical hard real-time systems

Often, the number of allowed misses is specified via probabilities(e.g., 10−7 or 10−9).

Burden is on the developer to proof that this is met.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 6 / 61

Soft Real-Time Systems

Characteristics

Missing a deadline is undesirable.

Computed values are useful after deadline.

Applications & Notes

Examples: online transaction systems, games, consumerelectronics

Class of systems: quality of service applications

Used with different terminology outside the real-time community

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 7 / 61

Usefulness Functions

Figure: Examples of usefulness functions.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 8 / 61

Is real-time = speed?

As in real-time object recognition, real-time image analysis, real-timedata aggregation, real-time strategy gaming?

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 9 / 61

Processors and Resources

Processors

They process jobs (exec. code, move data, process queries).

They have a type and are similar if they can be interchanged.

Multi-processor systems are declared as P1 . . .Pm.

Resources

Jobs require resources (memory, mutex, RS232, EEPROM).

Resources are acquired via locks (→ complex tasks).

Reusable vs. non-reusable resources

Plentiful resource (no job is every limited by this resource).

Discussion: resource vs. processor: networks?

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 10 / 61

Real-Time Workloads

A workload is a set of jobs which have to be processed.

Workloads can change at run time.

Assume parameters of workload are known for analysis.

a job Jfeasible interval is (ri , di ]

A priori knowledge vs. dynamic adjustment

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 11 / 61

Jitter and Job Releases

Jitter means fluctuations of a recurring event’s occurrence in time(e.g., release jitter [r−, r+]).

t

Ji

jitter

r−i r+i

Job Releases

Periodic: isochronously recurring

Sporadic: follows maximum inter-release time

Aperiodic: arbitrary

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 12 / 61

Execution Time

. . . is the time it takes to finish a task without interruption.

Properties

It can differ between runs.

The actual execution time of Ji is not of interest

. . . the bounds are: [e−i , e+i ].

Still, finding minimum and maximum execution time is hard.

Typically, for schedulability analysis ei means e+i .

Using only e+i causes problem of underutilization.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 13 / 61

Periodic Task Model: Ti = (pi , ei)

Basic Properties

Task is characterized by its period pi and execution time ei .

The task is released every pi time units.

Periodic vs strictly periodic

Surrounding Concepts

A task Ti can have consists of multiple jobs: Ji ,1 . . . Ji ,k .

Phase φi is release time of first job ri ,1.

The hyperperiod specifies the recurrence of the set of tasks.H = lcm(pi )

Often the analysis only has to go up to the hyperperiod.

Utilization of Ti = ei/pi (if di = pi )

Often: di = pi in periodic systems, but not necessarily

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 14 / 61

Precedence Constraints

. . . constrain the execution order based on processing requirements.

Job Precedence Constraints

... constrain the execution order of jobs inside tasks.

Partial-order relation < as precedence relation: Ji < Jj < Jk .

Ji is immediate predecessor of Jj .

A job is ready when all constraints are satisfied.

Usually represented by the precedence graphs G = (J , <).

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 15 / 61

Precedence Constraints

Task Precedence Constraints

... constrain the release of tasks.

Arbitrary complex structures and annotations:

AND/OR blocks, feasibility interval, conditional block

Figure: Example of task graphs.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 16 / 61

Data Dependency

. . . constrains the execution order based on read/write requirements.

They are different from processing order requirements.

Occur in producer/consumer settings.

Often neglected by implementing shared variables.

We’ll come back to this.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 17 / 61

Job Preemption

. . . means that a task can be suspended at any time.

Antonym: non-preemptable

Often only parts are non-preemptable.

Preemption mechanism requires context switch:

Save current processor stateLoad new processor stateClear pipeline

Context-switch time is the main run-time overhead.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 18 / 61

Critically of Jobs

... provides a partial order of task importance to the system.

Example: ABS >crit stereo sound

Used by admission control in overload situations

Used for graceful degradation

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 19 / 61

Mandatory vs. Optional

Jobs

The system still works, even if optional jobs are dumped.

Example: evasion detection is mandatory, evasion route not.

Parts of Jobs

The system still works, even if code parts are skipped.

Example: optimizing routes

→ imprecise computation

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 20 / 61

Scheduler and Schedules

Scheduler

... follows a policy and allocates resources to jobs.

Example: processor to execution, TDMA slot to communication

Clairvoyant scheduler is always optimal.

Schedule

... is an assignment of all jobs to available resources.

Valid schedule:

1 Every resource is assigned to at most one job at any time.2 Every job is assigned at most one resource at any time.3 Job consumption is satisfied (ET or WCET is allocated).4 All precedence and resource usage constraints are satisfied.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 21 / 61

Schedule Properties

Feasible schedule: valid + meets job’s timing constraints.

Scheduleable: set of jobs + execution alg. = feasible schedule

Makespan: response time of the job that completes last

Evaluation of Scheduling Algorithms

Does it always find a feasible schedule, if one exists?

Maximum and average tardiness?

Average response times, shorter makespan?

Miss rate, loss rate, invalid rate?

Objective depends on what is to be scheduled.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 22 / 61

Overview of Scheduling Policies

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 23 / 61

Clock-Driven Scheduling

... uses a stored schedule and makes decisions at specified times.

Usually clairvoyant scheduler

Offline generated schedule

Use timer interrupt online

Low overhead

t0

j1 j2 j3

next scheduling decision

Figure: One schedule (with gap) with r = 0, e1 = 2, e2 = e3 = 1.

More to come later...

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 24 / 61

Round-Robin Approach

... assigns one time slice to a job at a time.

t0

j1 j2 j3 j1

slice

Figure: Round-robin schedule with r = 0, e1 = 2, e2 = e3 = 1.

With n jobs, one job gets a slice every n times slices ( 1n th).

Weighted RR assigns slots based on weights.

Good for job pipelining, bad for precedence in general.

More to come later...

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 25 / 61

Priority-Driven Approach... is greedy and decides based on events.

If possible, never leaves the resource idle (locally optimal).

Uses a priority queue (=list)

Static vs dynamic priority assignment

Many different forms of assigning priorities

Figure: Precedence graph with 〈ji , ei 〉.

Example: r5 = 4 all other r = 0, Ji >p Jk if i < k.Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 26 / 61

Priority-Driven Approach Example

Figure: Using preemptive scheduling.

Is this the best we can do?

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 27 / 61

Priority-Driven Approach Example

Figure: Using non-preemptive scheduling.

Compare: preemptive (rt6 = 11) vs non-preemptive (rt6 = 12)However, in general non-preemptive is not better!

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 28 / 61

Dynamic vs. Static Dispatching

Dynamic Dispatching

Each job may run on any processor.

Each job may preempt any job on any processor.

Each job may resume on any processor (migrate).

Static Configuration

Jobs are partitioned into subsystems.

Subsystems are bound to processors.

Reconfiguration introduces flexibility.

Example: J1 to J4 on P1 and all remaining on P2.Discussion of recent results.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 29 / 61

Consistency of Observed Timings

Effective Release Time (r ∗)

... fixes the problem of: r2 > r1 and J2 < J1.

No predecessor → r∗ = r

Otherwise, r∗i = max(r∗j ∪ ri ) for all Jj < Ji .

Example:

r∗3 = 2, r∗6 = 4 . . .

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 30 / 61

Consistency of Observed Timings

Effective Relative Deadline (D∗)

... fixes the problem of: D1 > D2 and J2 > J1.

No successor → D∗ = D

Otherwise, D∗i = min(D∗

j ∪ Di ) for all Jj > Ji .

Example:

D∗4 = 9,D∗

3 = 12 . . .

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 31 / 61

What are r ? and D? good for?

... can ignore precedence constraints in schedulability check.

Do we need more accuracy?E.g., r? = max( (r?

j + e+j ) ∪ ri )?

On a one-processor system with preemptable jobs: no!

From now on r means r?.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 32 / 61

Earliest Deadline First (EDF)

Basics

Priority-driven approach

Ready queue is sorted: prioi > prioj , iff di < dj .

EDF is optimal with preemptive simple tasks.

Optimal means EDF produces a feasible schedule, if one exists.

Example:

0 t

J1, d1 = 8

J1

3J1 preempt!

J2, d2 = 5

J2

4.5f2!

J1 resumes

J1...

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 33 / 61

Proof of Optimality for EDF

TheoremWhen preemption is allowed and jobs do not contend for resources, theEDF algorithm can produce a feasible schedule of a set J of jobs witharbitrary release times and deadlines on a processor if and only if Jhas feasible schedules.

Proof intuition: Any feasible schedule of J can be transformed into anEDF schedule.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 34 / 61

Proof of Optimality for EDF

Basis

Parts of Ji and Jk are scheduled in intervals Ii and Ik .

di > dk but I1 is earlier that I2

Case 1

rk later than end of I1

→ adheres to EDF, because Jk cannot be scheduled

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 35 / 61

Proof of Optimality for EDF

Case 2

rk is before end of I1

solution: swap Ji and Jk and fit parts into I1 and I2

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 36 / 61

Proof of Optimality for EDF

Filling Gaps

Schedule might still have gaps

solution: swap idle time with already released tasks

→ as along as there is a feasible schedule, this algorithm generates the’EDF version’ of this schedule.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 37 / 61

Latest Release Time (LRT)

Basics

Finishing sooner doesn’t matter, if only deadlines matter.

Swaps deadlines and release time in sched. decision (=rev. EDF).

Can leave system idle → not a priority-driven algorithm.

Optimal similar to EDF.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 38 / 61

Least Slack Time First (LST)

Basics

... schedules: the smaller the slack, the higher the priority.

Priority-driven approach

LST is optimal

Example:

Ji , e (r ,D] J1, 3 (0, 6] J2, 2 (5, 9] J3, 2 (2, 6]

0 t

J1

J1

2slack(J1) = 3slack(J3) = 2

J3

J2

4f3!

J1 resumes

J1

5f1!

J3

7f2!

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 39 / 61

Comparison EDF, LRT, LST

Earliest Deadline First

Widespreadly known

Robust

Simple to implement

Latest Release Time

Good to fit in soft real-time tasks.

Requires precise execution time analysis!

Least Slack Time First

Requires knowledge of slack

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 40 / 61

Counter Examples To Optimality:Non-preemptability

Example

J = {J1 = 〈0, 3, 10〉, J2 = 〈2, 6, 14〉, J3 = 〈4, 4, 12〉} withJi = 〈r , e,D〉 using EDF.

Figure: EDF fails with non-preemptive tasks.

Figure: A feasible schedule exists!Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 41 / 61

Counter Examples To Optimality:Multi-Processor

Example

J = {J1 = 〈0, 1, 1〉, J2 = 〈0, 1, 2〉, J3 = 〈0, 5, 5〉} with Ji = 〈r , e,D〉using EDF on a 2-processor machine.

Figure: EDF fails on 2-processor system.

Figure: A feasible schedule exists!Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 42 / 61

Anomalies of Priority-Driven Systems

Example specification

Given J1 to J4 with prioi > prioj where i < j .

System is dynamic (=common priority queue).

Preemption but no job migration.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 43 / 61

Anomalies of Priority-Driven Systems

e2 = 6 (similar with e2 = 5)

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 44 / 61

Anomalies of Priority-Driven Systems

e2 = 2

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 45 / 61

Anomalies of Priority-Driven Systems

e2 = 3

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 46 / 61

Anomalies of Priority-Driven Systems

e2 = 5

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 47 / 61

Summary of Anomaly Example

e2 rt42 203 214 155 156 16

Take-away message

Scheduling anomalies make validation hard.

Anomalies exist even on single processor systems.

So, is this also true for preemptive uni-processor systems?

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 48 / 61

Uni-Processor Anomalies Are Non-Existent

... assuming indep. and preemptive jobs with prio.-driven algorithm.

Predictability of schedules

Actual schedule uses e

Maximal schedule uses only e+i

Minimal schedule uses only e−iSchedule is predictable if no anomalies in between.

Predictability of jobs

Use the maximal and minimal schedule for s+ and s−, resp.

Start-time predictable, if s−i < si < s+i

Completion-time predictable, if f −i < fi < f +i

Job is predictable if both apply.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 49 / 61

Proof for Non-Existence

TheoremThe execution of every job in a set of independent, preemptable jobswith fixed release times is predictable when scheduled in apriority-driven manner on one processor.

Proof

Assume: J1, J2, ...Ji−1 have higher priority than Ji and arepredictable. We show by contradiction that Ji (next priority level)is also predictable.

Suppose that s−i < si < s+i is not true.

Consider case si > s+i :

By s+i every higher priority has finished (max. schedule).

If si > s+i , then either idle [s+

i , si ] or lower priority job runs.Both cannot happen, according to priority-driven algorithm.

Similar argument for case si < s−i .

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 50 / 61

Proof for Non-Existence (contd.)

Proof contd.

Suppose F−i < fi , f

+i is not true.

Consider case fi > f +i :

[si , f+i ] is longer than [s+

i , f +i ]

If fi > f +i , then (a) gaps or (b) lower priority job runs.

Both cannot happen! (priority-driven algorithm)

Similar argument for case fi < f −i with minimal schedule.

→ Ji is start and completion-predictable!

Discussion

We can ignore variations in execution times (!!)

Validate using maximal & minimal schedule only

Independence is hard to achieve in complex systems

What about conventional ’non-tasks’ such as interrupts?

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 51 / 61

Validation Algorithm

... determines whether all jobs meet their deadlines.

Properties

Correctness: correct, if no false positives.

Execution time: some run in constant time.

Robustness: violating some assumptions still retains correctness.

Accuracy: accurate, if no false negatives.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 52 / 61

Offline vs Online Scheduling

Offline scheduling (vs. online)

Inflexible for run-time changes

Near optimal use of resource (esp. multi-resource)

No run-time overhead for complex scheduling decisions

Online scheduling is only possibility for unpredictable workloads.

Caveat: No optimal online schedule for this case!

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 53 / 61

No Optimal Online Scheduling

... assuming unpredictable workloads with non-preemptable jobs.

Example

J1 with ei = 1 and D1 = 1 arrives at t = 0. What to do?

0 t

J1 D1

J1

x

J2

1,d2

Figure: Case 1: Immediately?

0 t

J1 D1

J1

x < 1 y

J2

Figure: Case 1: Later?

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 54 / 61

Overload

... occurs when the workload cannot be scheduled (clairvoyant).

Clairvoyant scheduler knows everything (=optimal).

Overload implies discarding jobs.

Performance of handling overloads

Value of job vali =

{e if fi < Di ,

0 otherwise.

Value of schedule vals is the sum of all jobs in the sequence.

Optimality valo = always produce schedule of maximum possiblevalue.

Competitive factor c = vals/valo

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 55 / 61

EDF/LST and Overload

EDF and LST have a competitive factor of 0!

Example

J1t0

J1

ε

J2t

J2

Competitive factor

Optimal value = e1, EDF value = e2

c = e1e2

, with infinitely small e2: c = 0.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 56 / 61

Theoretic Limit on Competitive Factor

TheoremNo online scheduling algorithm can achieve a competitive factorgreater than 0.25 when the system is overloaded.

Setup

Adversary offers two jobs: major jobs Ji and assoc. jobs Jai .

Jobs have e = D (→ do it now or discard it)

Assoc. jobs have e = ε

Number of Jai for each Ji depend on scheduling decisions.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 57 / 61

Theoretic Limit on Competitive FactorAdversary slightly overload the system: ri = ri−1 + ei−1 − ε

Discard caseAt ri the scheduler discards Ji−1 and starts Ji :

Ji+1 is released with ri+1 computed as ri .

Discards until Jmax , and total value is emax

Clairvoyant would schedule all Jai instead and Jmax .

Completion case

The scheduler decides to complete Ji and then execute only Jai+1:

The adversary stops releasing further Jai+1.

Adversary pics ri+2 so that Ji+1 could have been executed.

The total value of the schedule will be ei + ε

Clairvoyant would schedule all Ji ;∑i

k=0 ek i < max

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 58 / 61

Theoretic Limit on Competitive Factor

Filling in the values

e0 = 1, i > 0 : ei = c · ei−1 −∑i

k=0 ek

competitive factor is

{emaxPmaxk=0 ek

discard case1c complete J1 and then Ja

Case 2 is always greater if i ≥ 4.

For 4, it’s 14 = 0.25.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 59 / 61

Theoretic Limit on c (Example)

The scheduler executes J2 to completion.

Schedule value is 8.

Clairvoyant schedule value is 32.

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 60 / 61

The End?

Hokus Pokus?

Sebastian Fischmeister, sfischme@ecemail.uwaterloo.ca 61 / 61

Recommended