Scuola Superiore Sant’Anna Contract-based scheduling Giuseppe Lipari
Mar 29, 2015
Scuola Superiore Sant’Anna
Contract-based scheduling
Giuseppe Lipari
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
2
Summary
• Overview of classical scheduling theory– Limitations of classical scheduling
• Contract based scheduling• Techniques:
– Resource Reservations and periodic servers– Bandwidth Inheritance
• Applications– Hard and soft real-time tasks– Supporting imprecise computation model with contracts
• Hierarchical scheduling– Component based systems
• Adaptive Systems– Feedback control
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
3
Classical Scheduling TheoryClassical Scheduling Theory
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
4
Classical Scheduling Theory
• In this presentation we address scheduling in mono-processor systems– The methodologies we describe are more general,
and can be applied to other resources
• Scheduling algorithm– An on-line algorithm that selects which task is to be
executed at each instant of time
• Problem – given a set of real-time tasks and a scheduling
algorithm, check a-priori if all timing constrains will be respected
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
5
Classical Task Model
• Real-Time system = set of concurrent real-time tasks• Task: sequence of jobs (or instances)
),,( iiii TDC
• Periodic or sporadic task– T is the period (or minimum inter-arrival time)
),,( ijijijij dcaJ
iijij
iij
iijij
ij
Dad
Cc
Taa
J1
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
6
Scheduling analysis
Task model(timing)
Implementation Scheduler Schedule
SchedulingAnalysis
ScheduleProperties
Designmodel
OFF- LINE
RUN-TIME
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
7
Scheduling Algorithms
• Table driven– Schedule is entirely computed off-line and stored in a table– Maximum degree of predictability, but too rigid– E.g. Time Triggered Architecture
• Fixed Priority– Each task is assigned a priority– Predictable but also flexible– The most popular (all RTOS implement FP)
• Earliest Deadline First– Each job has a priority inversely proportional to its deadline– Flexible and optimal– But not implemented in practice
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
8
Hard real-time systems
• Safety critical hard real-time applications– Severe consequences if some timing constraint is violated– Most important objective is to meet all timing constraints– Cost is a secondary issue– Fault-tolerance is a major issue – Design for Worst-Case– Overestimation of resources
• Examples:– Avionic and space systems– Nuclear plants– Etc.
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
9
Modern real-time applications
• A new class of real-time applications– Cost is an important factor– Overestimation of resources can unnecessarily increase the
cost– Strong push toward “adaptive” and “robust” techniques – E.g. automotive
• Soft real-time systems– Cost is a major factor– Optimization of resources is very important– Some timing constraint can be missed– Emphasis on Quality of Service control– Design for average case– E.g. Consumer Electronics, Multimedia systems, etc.
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
10
Limitations of classical scheduling
• An accurate timing analysis requires– An accurate model of the Hardware platform– An accurate model of the software (inputs/outputs/frequencies of
events)– Long and expensive– WCET can be much higher than average – Design for worst-case waste of resources increases the cost
Task model(timing)
Implementation Scheduler Schedule
SchedulingAnalysis
ScheduleProperties
Designmodel
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
11
Limitations of FP and EDF
• There is no “temporal protection”– Suppose that we underestimate the WCET of a task– The analysis will not report any problem– At run-time one or more tasks can miss their
deadlines
• Not all code is always under our control– In large projects, it is common to include code from
third-parties – A non critical task written by someone else could
compromise the schedulability analysis
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
12
task1
task2
Temporal fault
Executingmore than expected...
task2 fails!!
task1
task2
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
13
Example with EDF
• Three tasks scheduled by EDF– C1=1, T1=4– C2=?, T2=6– C3=2, T3=8
It’s executing too much... (5 instead of 3)
Deadline miss!
task1
task2
task3
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
14
Design for average case
• Consider a soft real-time application– Worst case >> Average case– Allow deadline miss but …– … keep them under control!
• If we use classical scheduling algorithms (FP or EDF)– Design for worst-case waste of resources– Design for average-case difficult to give guarantees
• Probabilistic schedulability analysis– The model is too complex (requires probabilistic
characterization of all tasks)– The behavior of one task depends on the behavior of every
other task– No easy “knob” to control QoS of tasks
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
15
Limitations of Fixed Priority
• Fixed Priority Scheduling– Each task is assigned a priority– The highest priority active task executes– Rate Monotonic assignment is optimal for schedulability and
resource utilization
• How to assign priorities? – What is the relation between priority and “importance /
criticality”?– More important / critical task should have higher priority– The most important tasks are not necessarily the ones with the
shorter periods– Lower priority tasks could be delayed by higher priority ones
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
16
Fixed priority and Components
• Example: – Consider two components developed independently. Each one
consists of two tasks, for a total of 4 tasks. The scheduler is FP (Fixed Priority).
• Problem:– Priorities are relative – The designer of one component can only assing local priorities– It is not clear how to transform local priorities into global
priorities at integration phase
• No temporal isolation– A failing task of one component can delay the execution of other
components
Problems with a single scheduler
Task1 Task2
Component C1
Task3 Task4
Component C2
Global scheduler
Task1 Task2 Task3 Task4
prio(Task1) > prio(Task2)prio(Task3) > prio(Task4)Possible priority ordering:1. prio(Task1) > prio(Task2) >
prio(Task3) > prio(Task4)
2. prio(Task1) > prio(Task3) > prio(Task2) > prio(Task4)
3. prio(Task3) > prio(Task1) >prio(Task2) > prio(Task4)
4. prio(Task3) > prio(Task4) >prio(Task1) > prio(Task2)
5. prio(Task1) > prio(Task3) >prio(Task4) > prio(Task2)
6. prio(Task3) > prio(Task1) >prio(Task4) > prio(Task2)
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
18
Schedulability Analysis
• Scheduling analysis can only be performed when1. We already have all tasks with their code
2. We have performed WCET analysis
• It is the final step!– Most of the times it comes too late– If the system is not schedulable, it is not easy to understand
how to change the system
• Scheduling analysis is not composable– Cannot be done separately on smaller subsystems– Requires too much effort and time– Only useful for safety critical systems
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
19
Summary: why RT analysis?
• What we ask real-time & embedded system developers– develop correct concurrent and distributed software– measure WCETs– make a real-time analysis– short time-to-market & cheap
• What do we give them– low level OS primitives– no integrated methodology for measuring WCETs– analysis tools not integrated in the process
• Real-time theory regarded as “solution to the wrong problem”
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
20
What we propose
• High-level real-time services– with built-in analysis– platform-independent– high-level quality of service management
• Temporal encapsulation of subsystems– Support the composability of independently developed
components– full view of resource protection (processors, networks, busses,
memory, power, ...)
• Designed for component-based design methodologies– as an enabling technology
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
21
Contract Based SchedulingContract Based Scheduling
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
22
Objectives
• A scheduling algorithm– Temporal protection– On-line admission control
• Appropriate OS primitives– Platform-independent– “standard”– That allow QoS management and control
• A scheduling analysis– Composable
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
23
FIRST and FRESCOR projects
• The FIRST project– 5th framework EU project, concluded in 2004– A platform independent API for contract-based scheduling– Implemented in two OS: MARTE and Shark– Implementation and documentation available at
http://shark.sssup.it
• The FRESCOR project– 6th framework EU project, started July 2006– Extend API to multiple resources, multiprocessors, Quality of
service management– Implementation will be performed on Linux and RT-Linux
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
24
Contracts
• The contract model– The application specifies its resource requirements in a
“contract”– The system performs an admission control test– If the contract is accepted, the application is admitted and
reserved a certain amount of resources– The contract can only be broken by the application itself
• Application– A single task– A set of tasks plus a local scheduler (for hierarchical
scheduling)
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
25
Real-Time Contracts
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
26
The contract model in FIRST
• Set of modules, each one contains the API for a specific and well defined subset of functionalities
DistributionDistribution
FirstSchedulingFramework
Shared objectsShared objects
Spare capacitysharing
Spare capacitysharing
CoreCore Implementationspecific
Implementationspecific
Hierarchicalschedulers
Hierarchicalschedulers
Dynamicreclamation
Dynamicreclamation
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
27
Contract parameters
• Core parameters– (Qmin, Qmax) min and max budget– (Pmin, Pmax) min and max budget– Deadline– Granularity = (discrete | continuous)– Signaling
• Negotiation– If it can be admitted, selects (Q, P)– At run-time, it guarantees Q every P units of time, within D
from the start
P
D
Q
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
28
Resource Reservations
• The underlying scheduling mechanism is based on Resource Reservations– Each application is reserved a fraction of the resource in terms
of (budget, period)– The application is guaranteed to receive at least that amount of
resource
• Resource Reservation algorithms– There are many, for FP and for EDF– FP: Polling server, Sporadic Server, Deferrable Server– EDF: Constant Bandwidth Server (CBS), GRUB, CASH, …
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
29
Resource Reservations
10 %
45 %25 %
20 %
1
23
4
Resource partition
Each application receives a bandwidth Ui = Qi / Pi
Resource enforcement
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 the other tasks.
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
30
Scheduling
• Each reservation is managed by a “server”– SERVER = An object internal to the OS that updates run-time
state of the reservation– Each Reservation can handle more than one task (hierarchical
scheduling)
1
2 CPU
serverReady queue
EDF
U1
U2
U3
U1 + U2 + U3 1
server
server
3
4
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
31
Virtual Processor Analogy
• A task in a reservation behaves approximately like on a dedicated virtual processor
• The approximation is given by the time granularity of the allocation (the period of the reservation P)
1
2
3
1
2
3
1 2 3
1
2
3
U2
U1
U3
PrioritizedAccess
ResourceReservation
P2
P1
P3
READY QUEUE
50%
30%
20%
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
32
Example with reservations
• Three processes, with reservations– Q1=1, P1=4, U = 0.25– Q2=3, P2=6, U = 0.5– Q3=2, P3=8, U = 0.25
Needs to execute 5 instead of 3...
Needs to execute 2…
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
33
Properties
• Individual timing guarantees– The ability of a task to meet its deadline depends only on the
amount of resources reserved to it– If a task wants to use more than reserved, it is delayed and
does not influence the rest of the tasks– Approximation of Virtual Processor
• Independence from underlying scheduling algorithm– The designer needs not to know about FP or EDF, but only
about the reservation
• Toward a component-based methodology– It is possible to analyze a subsystem independently of the
others!
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
34
Design Process
Task model(timing)
Implementation
Scheduler Schedule
SchedulingAnalysis
Sub-ScheduleProperties
Designmodel
OFF- LINE
RUN-TIME
Task model(timing)
Subsystem
Subsystem
Implementation
SchedulingAnalysis
Sub-ScheduleProperties
Contract
Contract
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
35
Guarantees and reclamation
• Negotiation– Schedulability test depends on underlying scheduling algorithm– FP: response time analysis for “servers”– EDF: utilization-based test or pseudo-polynomial test– Admission based on Qmin and Tmax
• Spare Capacity– If there is free space, the algorithm computes Qmin < Q < Qmax
and Pmin < P < Pmax
– Distribution of free space based on weights
• Dynamic reclamation– At run-time, use the extra capacity not used by other tasks– If (Q, P) has been negotiated, at run time the task can get more
than Q
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
36
Contract Negotiation
• Client/server structure:– the service thread is assigned a contract – response time:
– Service thread contract params: (Cmin, Tmax, D)– Computation time for negotiation: G
ServiceThread
msg queueUser
Thread
fsf_negotiate_contract()
msg queue
G TmaxDQmin R
DPQ
GR
1max
min
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
37
Scheduling techniquesScheduling techniques
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
38
Resource Reservation Scheduling
• Many scheduling algorithms– Aperiodic servers (Polling, Deferrable, Sporadic, Constant
Bandwidth Servers)– Many reclamation algorithms (CASH, BASH, IRIS, …)
• We present GRUB – (Greedy Reclamation of Unused Bandwidth)– A RR scheduling algorithm based on EDF– Based on CBS
• Properties– Virtual processor analogy– Dynamic reclamation of bandwidth– Can be used for hierarchical system
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
39
GRUB
• System = set of “servers”– A server is the run-time object that manages a reservation
• Server– Parameters: (Q, P), U = Q / P– Variables: d = server deadline, V = virtual time– States and transitions:
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
40
Rules
• Active servers – Servers not in inactive
activeS
iact
i
UU
• Initially, server is inactive
• When task is activated (1.a)– V=t, d=t+P
• While task execute– dV = dt U / Uact
• If V = d (and task not completed) (4)– Go to depleted until d = t
• When budget recharged (5)– V = t, d = d + P
• When task completes– until V < t, stay in completed (2.b)– When V ≥ t, go to inactive (2.c or 3)
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
41
d
An example of execution
t
V
U = 0.5P= 5
Inac
Cont.
Comp.
Depl.
An example of execution (VP analogy)
• Two tasks– Task 1 requires C=[2,4], T=8; it is assigned Q=4, P=8, U=0.5– Task 2 requires C=[4,8], T=12; it is assigned Q=6, P=12, U=0.5
Task1
VP1
Task2
VP2
Uact
0 2 4 6 8 10 12 14 16
0 2 4 6 8 10 12 14 16
0 2 4 6 8 10 12 14 16
t
V1
t
t
V2
(2)
(8)
(4)
inactive
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
43
Shared Resources
• Resource Reservations are for independent tasks• Interaction model
– Shared memory– Critical sections guarded by mutex semaphores– Blocking time due to locked critical sections– Tasks cannot be considered “independent” anymore
• Bandwidth Inheritance Protocol (BWI)– Extends Priority Inheritance to Resource Reservations– Temporal isolation between non-interacting servers is
maintained– Limited interference between interacting servers
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
44
Bandwidth Inheritance
• Priority Inheritance– A task inside a critical section inherits the priority of the blocked
tasks• Bandwidth Inheritance
– A task inside a critical section inherits the bandwidth (i.e. the pair Q, P) of the blocked tasks
– Interference: a task can steal the reservation of someone else only for the duration of one critical section
– It is possible to compute maximum interference (under certain conditions)
• Temporal isolation is broken but:– Interference limited to interaction tasks and limited to critical
sections– Non interacting tasks are temporally isolated
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
45
ApplicationsApplications
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
46
Hard real-time tasks
• Contract Parameters– Qmin=Qmax= WCET of the thread
– Pmin=Pmax= thread’s period
– D = thread’s deadline– budget overrun exception handling
• Advantages– The thread is protected from the other non-RT and
soft RT threads in the system (temporal isolation)– if dynamic reclaimation, the spare capacity of this
thread can be given to others
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
47
Soft real-time tasks
• Contract Parameters– Qmin – Qmax = variation of the execution time
– Pmin=Pmax= thread’s period
– D = thread’s deadline
• Advantages– Does not impact on other threads (temporal isolation)– minimum service is guaranteed– Takes advantage of capacity sharing and dynamic
reclamation (to minimize deadline misses)– can re-negotiate if it needs more
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
48
Imprecise computation model
• Thread consists of a mandatory part and N optional parts– WCET of mandatory part = M
– WCET of i-th optional part = Oi
• What is needed– Core + (capacity sharing) + (dynamic recl.) + (shared res. synch.)
• Contract Parameters– Cmin = M
– Cmax = M + O1 + ... + ON
– Tmin = Tmax = thread’s period
– D = thread’s deadline
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
49
Get remainingcapacity
If enough capacityexecute optionalpart
Example: thread structure for imprecise computation
void task_body(void *arg) { ... pthread_t my_pid = (pthread_t)(arg); int i; sys_gettime(&acttime); fsf_get_server(&server, my_pid);
while(1) { /* Mandatory Body */ for (i=0; i<N; i++) {
fsf_get_available_capacity(server, &capacity);if (capacity > O[i]) {
/* Optional Code */ }
else break; } ADDUSEC2TIMESPEC(uperiod,&acttime); fsf_schedule_next_timed_job(&acttime,&budget,&period, &budget_missed,&deadline_missed); } }
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
50
Evaluation of dynamic reclamation
• First experiment– 4 periodic tasks
• with variable execution time [1,15] msec, 100 msec period• Each one is assigned a budget of 15 msec over a period of 100 msec (15%)
– 2 non-periodic tasks trying to reclaim as much as they can• they are assigned two servers
• budget Qmin,max = 3 msec, period Pmin,max = 60 msec (5% each)
• Results
Task Expected bandwidth Actual received bandwidth
55% 16.93%
65% 16.94%
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
51
Evaluation of dynamic reclaimation
• Imprecise computation task experiment– workload, same as in the previous experiment
• 4 tasks, execution time [1,15] msec, period 100 msec (15%)
– One imprecise computation task, a mandatory part and 3 optional parts– mandatory execution requirement = 5 msec– budget = 5 msec, period = 50 msec
Part exec time
# exec %exec
mand. 5 400 100
opt. 1 1 195 48.75
opt. 2 2 186 46.5
opt. 3 4 69 17.25
Part exec time
# exec %exec
mand. 5 400 100
opt. 1 4 75 18.75
opt. 2 2 75 18.75
opt. 3 1 75 18.75
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
52
Hierarchical Systems and Components
Hierarchical Systems and Components
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
53
Why Hierarchical Real-Time systems?
• Simplify the design of complex distributed systems– system as hierarchy of components
• Independent design and implementation of sub-systems– separation between interface and implementation
• Re-use of existing and well-tested components– to reduce development cost
• Dynamic and on-line (re-)configuration– possibility to easily substitute or upgrade a
component, possibly on-line
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
54
Hierarchical systems
Global scheduler
Required Interface
Provided Interface
component C1
Required Interface
Provided Interface
component C2
Local Scheduler
Task 1
Task 2
Local Scheduler
Task 3Task 4
Task 5
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
55
Local scheduler
• Why?– Priorities are local (implementation dependent)– Different components may need different schedulers– By defining the schedule (i.e. the order of execution),
it is easier to test and validate the component in isolation
– It is possible to change priorities (or even the entire scheduler) without changing the interface
• Existing research– Feng and Mok RTSS ‘03, Shih and Lee RTSS ‘04
and ‘05, Lipari and Bini ECRTS ‘03 and JEC ‘05
Hierarchical scheduling 3/6
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
57
Global and local scheduler
C1
C2
C1
Task1
Task2
Global scheduler
Local scheduler for C1
temporalpartition
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
58
Analysis
Application asks resource
to Sj
Sj bids resource
to Application
If the amount of resource provided by Sj is
always enough to satisfy the requirements of Application then it is schedulable!
Sj
App.
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
60
Partitioning the time
• The amount of processing resources assigned to a component can be modeled by three parameters:
),,( rate
burstiness
delay
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
61
Virtual processor analogy
• The Resource Reservation behaves like a virtual processor– A processor of speed α times the speed of the
original processor– With a maximum delay Δ
• The delay is a measure of the “time granularity”– A resource reservation “approximates” a fluid
allocation of rate α – The approximation error is Δ
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
62
Distributed systems
C2
C1 C3
Platform 1 Platform 2 Platform 3
(40%, 1, 1) (40%, 1, 1)(20%, 2, 1)
Single processorNode 1 Node 2
Network
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
63
Analysis
• Analysis is done in the virtual processors• We have a distributed system, where each component
executes in a different virtual node• Communication is done through a virtual network
– if two virtual processors are mapped onto the same physical node, communication has zero delay
Platform 1 Platform 2 Platform 3
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
64
Holistic Analysis
• We adapted the holistic analysis (Tindell et al., ’94) to the case of virtual processors
• The system is transformed into a set of “transactions”• A transaction is a chain of tasks• A task is a portion of a thread
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
65
Holistic Analysis
• Fix the reservation parameters (Q, P)– derive parameters (, )
• Iterative algorithm– Each task in a transaction has offset and jitter– Initially all jitters = 0– Calculate response time for each task (depends on
, )– jitter = response time of previous task– iterate until response time converges
• If response times < deadlines, schedulable
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
66
Quality of Service ControlQuality of Service Control
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
67
QoS management
• Problem with resource reservation– Thanks to resource reservation, we can analyze a task in
isolation!– ... but how much bandwidth should a task be assigned?– The execution requirements of a task depend on the hardware
of the system and on the input data
• Two different sub-problems– For a normal task, with constant execution time, we must assign
the initial reservation– For tasks with highly variable execution times, we must
dynamically adjust the bandwidth– Example: MPEG players
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
68
Feedback control
Note: Data files are courtesy of Philips Research
• Possible solution– feedback control to
dynamically adjust the assigned bandwidth
• Why feedback control?– Resource demand vary
in time
– A static allocation can, at certain times, be overly conservative and, at others determine performance degradations
Feedback scheduling
• One controller per task– the controlling strategy depends on the kind of application
• Each controller tries to set the scheduling error to 0– The scheduling error is the difference between the expected finishing time
and the actual finishing time
QoS Manager
Proc P1
Proc P2
Proc P3
QoS SchedulerQoS Supervisor
Controller 1
Controller 2
Controller 3
Q1
Q2
Q3
Q’1
Q’2
Q’3
1
2
3
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
70
Case study: the Xine media player
• A multi-standard video player– multi-thread (two pipelines of threads)– resource reservation and feedback applied only to
the Video Decoder thread
DeMux
Video Decoder
AudioDecoder
Synchro Visualizer
Disk
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
71
Results
• Fixed bandwidth equal to average (U = 12.6%)
• Great degradation of the quality of service
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
72
Results
• Fixed bandwidth equal more than average (U = 14%)
• Not enough for peak, but also some wasted bandwidth
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
73
Results
• Bandwidth dynamically adapted via feedback control
• Average allocated bandwidth: U = 13%
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
74
AQuOSA manager component
• Components– Kernel module– Application library – feedback controller sub-components
• Features– possibility to specify min / max budget allocations– the actual budget may vary between min/max– possibility to specify a different feedback scheduler
for each process
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
75
Bibliography
GRUB algorithm
[Lip00] G.Lipari and S.K. Baruah "Greedy reclaimation of unused bandwidth in constant bandwidth servers" IEEE Proceedings of the 12th Euromicro Conference on Real-Time Systems, Stokholm, Sweden, June 2000
[Sco07] Claudio Scordino, Giuseppe Lipari, “A Resource Reservation Algorithm for Power-Aware Scheduling of Periodic and Aperiodic Real-Time Tasks”, IEEE Transactions on Computers (2006)
IRIS Algorithm
[Mar04] Luca Marzario, Giuseppe Lipari, Patricia Balbastre, Alfons Crespo, "IRIS: a new reclaiming algorithm for server-based real-time systems", Real-Time Application Symposium (RTAS 04), Toronto (Canada), May 2004
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
76
Bibliography
BWI protocol
[Lip06] Lipari G., Abeni L., Lamastra G. “Task Synchronisation in Reservation-Based Real-Time Systems”, IEEE Transactions on Computers (2004)
Hierarchical Systems
[Bin04] Giuseppe Lipari, Enrico Bini, “A methodology for designing hierarchical scheduling systems”, Journal of Embedded Computing (2004)
[Lor06] José Lorente, Giuseppe Lipari, Enrico Bini, “A Hierarchical Scheduling Model for Component-Based Real-Time Systems” Workshop on Parallel and Distributed Real-Time System, (2006)
23 Feb. 2007 MOTIVES - ARTIST 2 Winter School
77
Bibliography
QoS adaptation mechanisms
[Pal05] Luca Abeni, Tommaso Cucinotta, Luca Marzario, Luigi Palopoli, Giuseppe Lipari, “QoS Management through Adaptive Reservations”, Real-Time Systems (2005)
FSF framework
[Gon06] M. Aldea et al. “FSF: A Real-Time Scheduling Architecture Framework”, Proceedings of the 12th IEEE Real-Time and Embedded Technology and Applications Symposium (2006)
Summary on Soft Real-Time Systems
[But06] Giorgio Buttazzo, Giuseppe Lipari, Luca Abeni and Marco Caccamo, Soft Real-Time Systems: Predictability vs. Efficiency, Springer, January 2005