Dynamic workload Several applications (e.g., multimedia systems) - - PDF document

SLIDE 1

1

load

Dynamic workload

Several applications (e.g., multimedia systems) are characterized by highly variable computational requirements:

time avg

Example: phone call

It consists at least of 2 periodic tasks, executed every 20 ms:

RX modem processor Ci-min = 1 ms (silence) Ci-max = 3 ms Receives audio signal, decodes it, and transfers packets to the speaker buffer for reproduction. RX TX

Overall CPU bandwidth: 30-65%

Voice sampling, data encoding, speech enhancement, and packet transmission through the modem. Ci-min = 5 ms (silence) Ci-max = 10 ms

Example: video playing

MPEG standard encodes frames in "Group of Pictures" (GOP), consisting into 3 types of frames:

• I frames (Inter-frames) include the entire content of a picture;
• B frames, (Backwards predictive) look backwards at the I

frames and P frames;

• P frames (Predictive) looks forward at the frame, constantly

comparing frame content. PAL standard:

• frame rate = 25 fps
• decoding time: 2-20 ms

I-frames can take 10 times more than B-frames

Mpeg decoding

density

Frame execution times distribution for “Star Wars”

Decoding time (s)

Probability d

Other causes of overloads

• Optimistic system design (based on average

rather than worst-case behavior)

• Malfunctioning of input devices (sensors may

send sequence of interrupts in bursts)

• Variations in the environment
• Simultaneous arrivals of events
• Exceptions raised by the kernel

SLIDE 2

2

Load definitions

C   

 Soft aperiodic tasks:



  

n i i i

T C U

1

 Hard periodic tasks:

 i i

T

1

       

1 2 2 1 ,

) , ( max

2 1

t t t t g

t t



if g(t1, t2) is the processor demand in [t1, t2], then:

 Generic RT application:

1 Does not consider past or future activations, but

• nly current jobs:

Instantaneous load (t)

2 4 6 8 10 12 14

2 3

t Maximum processor demand among those intervals from the current time and the deadlines of all active tasks.

Instantaneous load (t)

t ci



) (

We can have at most one deadline for each active task k, hence:

) ( max ) ( t t

k k

   t d t

k i d d k

k i

 





) ( ) ( 

Example

1(4) = 2/4 = 0.5 2(4) = 5/6 = 0.83  (4) 7/9 0 78

1 2 3

3(4) = 7/9 = 0.78 (4) = 0.83

2 4 6 8 10 12 14

3

1

(t)

2 4 6 8 10 12 14 0.5

Load and design assumptions

System designed under worst-case assumptios

1 0.75

load

1 0.75

load System designed under average-case assumptios

0.5 0.25

time

0.5 0.25

time

A matter of cost

 High predictability and low efficiency means wasting resources  high cost

– it can be justified only for very critical systems

Hi h ffi i i i  High efficiency in resource usage requires a the system to:

– handle and tolerate overloads – adapt for graceful degradation – plan for exception handling mechanisms

SLIDE 3

3

Definitions

Overrun: Situation in which a task exceeds its expected utilization.

Execution Overrun The task computation time exceeds its expected value: Activation Overrun The next task activation occurs before its expected time:

expected interarrival time

Transient Overload max > 1 but avg  1 Permanent Overload avg > 1

Overload: Situation in which (t) > 1.

Definitions

1 0.75 0.5 0.25

 time

1 0.75 0.5 0.25

 time

A task overrun may not cause an overload:

Consequences of overruns

1 2

1

8 4 8 12 6 2 10

• verrun

1 2

1

8 4 8 12 6 2 10

• verrun

deadline miss

But in general may delay the execution of other tasks, causing a deadline miss:

1

(2/4)

20 12 4 8 16

Consider the following applications with U < 1:

24

Consequences of overruns

6 18 20 12 4 12 8 16 12

2

(2/6)

3

(1/12)

24 24 24 20 12 4 8 16

U < 1 but sporadic overruns can prevent 3 to run:

24

early completion execution overrun

1

(2/4)

Consequences of overruns

6 18 20 12 4 12 8 16 12 24 24 24

2

(2/6)

3

(1/12)

Example of overload

In engine control, some tasks are activated at specific angles of the crankshaft.

The activation rate

• f

these tasks is proportional to the angular velocity  of the engine: t

u() = 2 C 



1

*

* = 2 C

SLIDE 4

4

Example of overload

engine task (high priority) Function loss

Car speed

time

From now on the car cannot decelerate!

Load control methods

Overrun handling Overload handling Resource Reservation Reactive vs. Proactive Local vs. Global

Providing temporal isolation

Transient

• verloads

can be handled through Resource Reservation: a mechanism to bound the resource consumption of a task set to limit the interference caused to other tasks. To implement Resource Reservation we have to:

• reserve a fraction of the processor bandwidth to a

set of tasks;

• prevent the task set to use more than the reserved

fraction.

10 % 20 %

1 4 Resource partition Resource enforcement

Resource Reservation

45 % 25 %

2 3 Each task receives a bandwidth

i

and behaves as it were executing alone on a slower processor of speed i

 A mechanism that prevents a task to consume more than its reserved amount.  If a task executes more, it is delayed, preserving the resource for other tasks.

1 2 3 1 2 3

Prioritized Access

P2 P1 P3

READY QUEUE

Priorities vs. Reservations

1 2 3 1 2 3

1 = 0.5 Resource Reservation

50% 30% 20%

2 = 0.3 3 = 0.2

SLIDE 5

5

1 2 3

Prioritized Access

Priorities vs. Reservations

1 2 3

Resource Reservation

50% 30% 20%

Benefits of Resource Reservation

• 1. Resource allocation is easier than priority mapping.
• 2. It provides temporal isolation: overruns occurring in

a reservation do not affect other tasks.

• Important for modularity and scalability

p y y

• 3. Simpler schedulability analysis:
• Response times
• nly depends
• n the application

demand and the amount of reserved resource.

• 4. Easier probabilistic approach

CPU

server Ready queue scheduler

1 

1

server server

2b 2a

Implementing RR

2 3

3

server

Dynamic priorities server scheduler RM/DM EDF CBS Sporadic Server Fixed priorities

Analysis under RR

CPU

server Ready queue scheduler

1 

server server

2b 2a

1 2 3 If a processor is partitioned into n reservations, we must have that:

A n i i

Ulub

1









3

server

where A is the adopted scheduling algorithm. HARD: when the budget is exhausted, the server is blocked until the next budget replenishment.

Types of reservations

SOFT: when the budget is exhausted, the server remains active but at a lower priority level. Note that

• a HARD reservation (Qs, Ps) guarantees at most

a budget Qs every period Ps

• a SOFT reservation (Qs, Ps) guarantees at least

a budget Qs every period Ps

Soft CBS

The original CBS formulation implements a SOFT reservation:

Ps Ps

5

In fact, more the Qs units can be executed in an interval Ps if the processor is available.

Qs = 3 Ps = 9

3 6 9 12 15 18 21 24 3 6 9 12 15 18 21 24

1 2

5

SLIDE 6

6

Problem with soft reservations

The use of idle times from a server can cause irregular job executions and long delays:

6

Ps Ps Ps Ps Ps

1 1 1

Qs = 1 Ps = 3

3 6 9 12 15 18 21 24 3 6 9 12 15 18 21 24

1 2

6 10 1 1 1

long delay

Example with Hard CBS

1

4 12 24 8 16 20

16

The deadline aging problem can be avoided by suspending the server when qs = 0 and recharging the budget at ds:

32

CBS: Qs = 1, Ts = 4

s

8 12

d0

5

d1 d2

1

d3 d4

2 4 6 8 10

qs

12 14 16 18 20 22 24 26 24 20

d5 d6

4 16

1 1 1

28 28

Hierarchical scheduling

Resource reservation can be used to develop hierarchical systems, where each component is implemented within a reservation:

Application 1 Application N

Local Scheduler Global Scheduler Local Scheduler

Component 1 Component N

  

Computing Platform

In general, a component can also be divided in other sub-components

Local Scheduler Local Scheduler

Hierarchical scheduling

Local Scheduler Global Scheduler Local Scheduler

Component 1 Component N

  

Computing Platform

    

Server S1 Server S4

Global scheduler: the one managing the system ready queue Local schedulers: the ones managing the servers queues

Hierarchical scheduling

CPU

Global scheduler

S1 S2 S3 S4 1 2 3

Local scheduler

8 9

Local scheduler

  

Hierarchical Analysis

Application 1 Application N

Global analysis: Servers must be schedulable by the global scheduler running on the physical platform. Local analysis: Applications must be scheduled by the local schedulers running on the components.

Local Scheduler

Global Scheduler

Local Scheduler

Component 1 Component N

  

Computing Platform

SLIDE 7

7

D t  

Processor Demand Criterion (under EDF)

Analysis under RR

t t dbf  ) (

processing time available in [0,t] Timing behavior

• f the application

Workload Analysis (under fixed priorities): n i ,..., 1  

t t Wi  ) (

: ] , (

i

D t   available in [0,t]

• f the application

Wi(t) = Ci + Ck Tk t

k=1 i–1

Σ

t t dbf t    ) ( ,

Under EDF, the analysis of an application within a reservation is done through the Processor Demand Criterion: U d Fi d P i it S t (FPS) th l i i

Analysis under RR

The difference is that in an interval of length t the processor is only partially available. Under Fixed Priority Systems (FPS), the analysis is done through the Workload Analysis: : ] , ( ,..., 1

i

D t n i    

t t Wi  ) (

To describe the time available in a reservation, we need to identify, for any interval [0,t], the minimum time allocated in the worst-case situation. Supply bound function sbf(t):

Analysis under RR

Supply bound function sbf(t): minimum amount of time available in reservation Rk in every time interval of length t.

Example: Static time partition

2 4 6 8 10 12 14 16 18 20 22 24

t

Example of reservation providing 4 units every 10 (bandwidth = 0.4). sbf(t)

t

2 4 6 8 10 12 14 16 18 20 4 8

) ( ) ( , t sbf t dbf t   

Hence the Processor Demand Criterion can be reformulated as follows:

Analysis under RR

t

dbf(t)

t

sbf(t)

) ( ) ( , t slbf t dbf t   

A simpler sufficient test, can be done by replacing

sbf(t) with a lower bound, called supply lower-bound

function slbf(t):

Analysis under RR

sbf(t)

t

dbf(t)

t

slbf(t)

SLIDE 8

8

Supply lower-bound function

)} ( , max{ ) (    t t slbf 

A supply bound function has the following form:  = bandwidth i d l

t

slbf(t)    = service delay Given a generic supply function sbf(t), the bandwidth  is the equivalent slope computed for long intervals: sbf(t)

t t sbf

t

) ( lim

 

 

Deriving  and 

sbf(t)

t

t

t  

 While the delay  is the highest intersection with the time axis of the line of slope  touching the sbf(t): sbf(t)

        



 ) ( sup t sbf t

t

Deriving  and 

sbf(t)

t

 

t

sbf(t) sbf(t) 

Example: Periodic Server

For a periodic server with budget Qs and period Ps running at the highest priority, we have:

s s

P Q  

s s

Q P    Qs Ps sbf(t) Qs Ps – Qs Qs For a periodic server with budget Qs and period Ps running at unknown priority, we have: Qs Ps

s s

P Q   ) ( 2

s s

Q P   

Example: Periodic Server

sbf(t) Qs 2(Ps – Qs) Qs

Observation

It is worth comparing the following supply functions: t

Supply function of a full processor Supply function

• f a fluid partition

with bandwidth  Supply function of a real partition with bandwidth 

• f a periodic server Q,P

t

  t 

SLIDE 9

9

In a periodic server with bandwidth , we have that: P Q   ) 1 ( 2 ) ( 2       P Q P

The delay  is proportional to the server period P

Observation

t

  t  Note that, for a given bandwidth , reducing P reduces the delay  and improves schedulability, tending to a fluid reservation, but … smaller periods generates higher runtime overhead

Observation

t smaller P

higher runtime overhead If  is the context switch overhead, we have:

Taking overhead into account



Q P Q 

eff

   

min

P                1 2 ) 1 ( 2

min min

P

Allocated bandwidth: Effective bandwidth:

P Q   P P Q

eff

        ) 1 ( 2     P Hence reducing the server period P reduces the delay , but also reduces the effective bandwidth eff that can be exploited:

Effective bandwidth

eff P

eff

     P

/



Reservation interface

Note that the (, ) parameters offer an alternative interface, which is independent of the implementation mechanism (static partitions or Q-P server):

QoS1 QoS2 QoS3

1 1 2 2 3 3

1 2 3

Avoiding resource wastes

demanded bandwidth avg allocated bandwidth

A reservation can be wasted because of

• occasional load reduction due to early terminations
• wrong bandwidth allocation at design time
• application changes due to environmental changes

time under utilized correctly utilized

• ver utilized

SLIDE 10

10

Bandwidth allocation error

bandwidth allocation error

Resource is insufficient (application is delayed)  Bandwidth allocation error Demanded Bandwidth Allocated Bandwidth 

time error

The application demands less (resource is wasted)

Resource Reclaiming

R1

Unused bandwidth in a reservation can be used to satisfy extra occasional needs in another reservation:

R2

Budget reclaiming

3 2 2 1 2 3 4 4 3 1

CASH: Capacity Sharing algorithm

1 2

CASH: Capacity Sharing algorithm

• When a job finishes and qs > 0, the residual budget is put in

a global queue of spare capacities (the CASH queue), with a deadline equal to the server deadline.

• A server first uses the capacity in the CASH queue with the

earliest deadline dq  ds, otherwise qs is used.

• Idle times consume the capacity in the CASH queue with

the earliest deadline.

3 2 2 1 2 3 4 5 3 3

Capacity Sharing algorithm

1 2

1 1 2 1 3 4 5 3 2 2 1 2 3 3

CASH queue

Handling wrong allocations

There are situations in which the reservation error is caused by a wrong bandwidth allocation: any reservation is not appropriate

safe but time resource needs safe but not efficient efficient but not enough

Need for adaptivity

In these cases, the only solution is to design the system to be adaptive so that reservations can be changed based on runtime requirements:

time resource needs

SLIDE 11

11

Adaptive QoS Management

Reservation parameters can be changed at run time by a Reservation Manager: Reservation Manager

demand

QoS1 QoS2 QoS3

1 1 2 2 3 3

1 2 3

Local adaptation

A local adaptation approach is also possible for a task to comply with the assigned reservation:

i

Reservation   Reservation Ci Ti Local Policy Local Policy

probes

Real-Time System

Shared Resources

CPU

server Ready queue scheduler

1 

server server

2b 2a

2 3 R

3

server

Tasks are usually not independent: they share resources! Examples: Data Structures, Peripheral Devices, Common Memory Areas  Resource sharing may break isolation:

Problems with Reservations

deadline miss wait normal blocking due to reasource sharing extra blocking due to budget exhaustion

1

server

S2

2

wait Ts

 Resource sharing may break isolation:

Problems with Reservations

deadline miss wait The major problem is that the resource is locked but no task is actually using it

1

server

S2

2

wait Ts

SLIDE 12

12

Reactive approaches

Possible approaches

Let the budget finishes and react with a given strategy:

• Overrun
• Without payback
• With payback

Proactive approaches

• Proxy execution (BWI)

Prevent the budget to finish inside a critical section:

• Check and wait (SIRAP)
• Check and recharge (BROE)

Overrun without Payback

When the budget exhausts inside a critical section, just do nothing. Isolation is broken!

1

server

S2

2

Ts wait The budget goes negative

Overrun without Payback

Let k be the length of the critical section to be entered. In the worst-case the server consumes Qs +k budget units

server

S2

2

Ts wait

k k

Overrun with Payback

When the budget exhausts inside a critical section, just do nothing, but payback at the next budget replenishment. Isolation is broken!

Note that the worst-case bandwidth consumption does not change!

1

server

S2

2

Ts wait Budget payback The budget goes negative

Proxy Execution

When the budget exhausts inside a critical section, the server can inherit the bandwidth from another server.

1

wait

2 1

Bandwidth Inheritance Protocol (BWI)

server

S2

2

Ts

server

S1

wait

Proactive Approaches

• Let k be the length of the critical section to be entered,

and qs be the budget of the server at the lock time;

• Proactive approaches are based on a budget check

before locking the resource (i.e., qs  k ?);

• The scheduler requires the knowledge of  at run time
• The scheduler requires the knowledge of k at run-time.

qs  k ? NO qs  k ? YES

SLIDE 13

13

Check and wait

SIRAP

If (qs  k) then enter, else wait for the next replenishment. Note that off-line we must guarantee that Qs  max{k}.

checking point

1

server

S2

2

Ts wait

SIRAP

• It penalizes the response-time of the task wishing

to access the resource.

• It potentially inserts idle-time (unused budget).

checking point

1

server

S2

2

Ts wait

Check and recharge

If (qs  k) then enter, else recharge the budget at full value and proportionally postpone the server deadline.

BROE

Note that off-line we must guarantee that Qs  max{k}.

checking point

1

server

S2

2

wait

BROE

• It performs better than SIRAP in most situations.
• BROE works only with EDF-scheduled reservation

servers.

checking point

1

server

S2

2

wait

BROE

• BROE is designed to guarantee a bounded-delay

partition (, ).

• A budget recharge of x units of time corresponds to

a proportional deadline shift of x/

server

S2

2

Ts

x/

BROE

Note that a deadline shift of x/ guarantees that the server never consumes a bandwidth higher than , provided that





 

i j j i

1  

     D D x Q     x x Q D x Q D D        

 Q D  In fact, since the deadline increment D that guarantees a bandwidth  with a budget (Q + x) can be found by imposing: thus: