1. Scuola Superiore SantAnna Contract-based scheduling Giuseppe Lipari

2. 23 Feb. 2007MOTIVES - 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

3. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 3 Classical Scheduling Theory

4. 23 Feb. 2007MOTIVES - 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

5. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 5 Classical Task Model Real-Time system = set of concurrent real-time tasks Task: sequence of jobs (or instances) Periodic or sporadic task –T is the period (or minimum inter-arrival time)

6. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 6 Scheduling analysis Task model (timing) ImplementationSchedulerSchedule Scheduling Analysis Schedule Properties Design model OFF- LINE RUN-TIME

7. 23 Feb. 2007MOTIVES - 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

8. 23 Feb. 2007MOTIVES - 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.

9. 23 Feb. 2007MOTIVES - 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.

10. 23 Feb. 2007MOTIVES - 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) ImplementationSchedulerSchedule Scheduling Analysis Schedule Properties Design model

11. 23 Feb. 2007MOTIVES - 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

12. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 12 task 1 task 2 Temporal fault Executing more than expected... task 2 fails!! task 1 task 2

13. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 13 Example with EDF Three tasks scheduled by EDF –C 1 =1, T 1 =4 –C 2 =?, T 2 =6 –C 3 =2, T 3 =8 Its executing too much... (5 instead of 3) Deadline miss! task 1 task 2 task 3

14. 23 Feb. 2007MOTIVES - 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

15. 23 Feb. 2007MOTIVES - 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

16. 23 Feb. 2007MOTIVES - 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

17. Problems with a single scheduler Task1Task2 Component C 1 Task3Task4 Component C 2 Global scheduler Task1Task2Task3Task4 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)

18. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 18 Schedulability Analysis Scheduling analysis can only be performed when 1.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

19. 23 Feb. 2007MOTIVES - 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

20. 23 Feb. 2007MOTIVES - 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

21. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 21 Contract Based Scheduling

22. 23 Feb. 2007MOTIVES - 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. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 23 FIRST and FRESCOR projects The FIRST project –5 th 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 http://shark.sssup.it The FRESCOR project –6 th 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

24. 23 Feb. 2007MOTIVES - 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)

25. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 25 Real-Time Contracts

26. 23 Feb. 2007MOTIVES - 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 Distribution First Scheduling Framework Shared objects Spare capacity sharing Spare capacity sharing Core Implementation specific Implementation specific Hierarchical schedulers Hierarchical schedulers Dynamic reclamation Dynamic reclamation

27. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 27 Contract parameters Core parameters –(Q min, Q max ) min and max budget –(P min, P max ) 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

28. 23 Feb. 2007MOTIVES - 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, …

29. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 29 Resource Reservations 10 % 45 % 25 % 20 % 1 2 3 4 Resource partition Each application receives a bandwidth U i = Q i / P i 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.

30. 23 Feb. 2007MOTIVES - 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 server Ready queue EDF U1U1 U2U2 U3U3 U 1 + U 2 + U 3 1 server 3 4

31. 23 Feb. 2007MOTIVES - 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 U2U2 U1U1 U3U3 Prioritized Access Resource Reservation P2P2 P1P1 P3P3 READY QUEUE 50% 30% 20%

32. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 32 Example with reservations Three processes, with reservations –Q 1 =1, P 1 =4, U = 0.25 –Q 2 =3, P 2 =6, U = 0.5 –Q 3 =2, P 3 =8, U = 0.25 Needs to execute 5 instead of 3... Needs to execute 2…

33. 23 Feb. 2007MOTIVES - 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!

34. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 34 Design Process Task model (timing) Implementation SchedulerSchedule Scheduling Analysis Sub-Schedule Properties Design model OFF- LINE RUN-TIME Task model (timing) Subsystem Implementation Scheduling Analysis Sub-Schedule Properties Contract

35. 23 Feb. 2007MOTIVES - 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 Q min and T max Spare Capacity –If there is free space, the algorithm computes Q min < Q < Q max and P min < P < P max –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

36. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 36 Contract Negotiation Client/server structure: –the service thread is assigned a contract –response time: –Service thread contract params: (C min, T max, D) –Computation time for negotiation: G Service Thread msg queue User Thread fsf_negotiate_contract() msg queue G T max D Q min R

37. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 37 Scheduling techniques

38. 23 Feb. 2007MOTIVES - 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

39. 23 Feb. 2007MOTIVES - 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:

40. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 40 Rules Active servers –Servers not in inactive Initially, server is inactive When task is activated (1.a) –V=t, d=t+P While task execute –dV = dt U / U act 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)

41. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 41 d An example of execution t V U = 0.5 P= 5 Inac Cont. Comp. Depl.

42. 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 Task 1 VP 1 Task 2 VP 2 U act 0246810121416 0246810121416 0246810121416 t V1V1 t t V2V2 (2) (8) (4) inactive

43. 23 Feb. 2007MOTIVES - 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

44. 23 Feb. 2007MOTIVES - 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

45. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 45 Applications

46. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 46 Hard real-time tasks Contract Parameters –Q min =Q max = WCET of the thread –P min =P max = threads period –D = threads 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

47. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 47 Soft real-time tasks Contract Parameters –Q min – Q max = variation of the execution time –P min =P max = threads period –D = threads 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

48. 23 Feb. 2007MOTIVES - 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 = O i What is needed –Core + (capacity sharing) + (dynamic recl.) + (shared res. synch.) Contract Parameters –C min = M –C max = M + O 1 +... + O N –T min = T max = threads period –D = threads deadline

49. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 49 Get remaining capacity If enough capacity execute optional part 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); }

50. 23 Feb. 2007MOTIVES - 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 Q min,max = 3 msec, period P min,max = 60 msec (5% each) Results TaskExpected bandwidthActual received bandwidth 5 5%16.93% 6 5%16.94%

51. 23 Feb. 2007MOTIVES - 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 Partexec time # exec%exec mand.5400100 opt. 1119548.75 opt. 2218646.5 opt. 346917.25 Partexec time # exec%exec mand.5400100 opt. 147518.75 opt. 227518.75 opt. 317518.75

52. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 52 Hierarchical Systems and Components Hierarchical Systems and Components

53. 23 Feb. 2007MOTIVES - 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

54. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 54 Hierarchical systems Global scheduler Required Interface Provided Interface component C 1 Required Interface Provided Interface component C 2 Local Scheduler Task 1 Task 2 Local Scheduler Task 3 Task 4 Task 5

55. 23 Feb. 2007MOTIVES - 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

56. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 56 Global and local scheduling Separation of concerns –Role of the global scheduler Partition the time line into time slices, and allocate time slices to different components –The global scheduler does not need to know the internal structure of the components –Role of the local scheduler Schedule tasks inside the allocated time slices C1C1 C2C2

57. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 57 Global and local scheduler C1C1 C2C2 C1C1 Task 1 Task 2 Global scheduler Local scheduler for C 1 temporal partition

58. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 58 Analysis Application asks resource to S j S j bids resource to Application If the amount of resource provided by S j is always enough to satisfy the requirements of Application then it is schedulable! SjSj App.

59. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 59 Analysis Resource provided by a time partition –Can be done statically (e.g. TDMA) –Or dynamically (e.g. Resource Reservations) Parameters of a partition: –Delay Δ : maximum delay before execution –Rate α : average rate of resource allocation αtαt Δ

60. 23 Feb. 2007MOTIVES - 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

61. 23 Feb. 2007MOTIVES - 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 Δ

62. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 62 Distributed systems C2C2 C1C1 C3C3 Platform 1Platform 2Platform 3 (40%, 1, 1) (20%, 2, 1) Single processor Node 1Node 2 Network

63. 23 Feb. 2007MOTIVES - 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 1Platform 2Platform 3

64. 23 Feb. 2007MOTIVES - 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

65. 23 Feb. 2007MOTIVES - 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

66. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 66 Quality of Service Control

67. 23 Feb. 2007MOTIVES - 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

68. 23 Feb. 2007MOTIVES - 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

69. 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 P 1 Proc P 2 Proc P 3 QoS SchedulerQoS Supervisor Controller 1 Controller 2 Controller 3 Q1Q1 Q2Q2 Q3Q3 Q1Q1 Q2Q2 Q3Q3 1 2 3

70. 23 Feb. 2007MOTIVES - 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 Audio Decoder SynchroVisualizer Disk

71. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 71 Results Fixed bandwidth equal to average (U = 12.6%) Great degradation of the quality of service

72. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 72 Results Fixed bandwidth equal more than average (U = 14%) Not enough for peak, but also some wasted bandwidth

73. 23 Feb. 2007MOTIVES - ARTIST 2 Winter School 73 Results Bandwidth dynamically adapted via feedback control Average allocated bandwidth: U = 13%

74. 23 Feb. 2007MOTIVES - 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

75. 23 Feb. 2007MOTIVES - 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

76. 23 Feb. 2007MOTIVES - 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)A Hierarchical Scheduling Model for Component-Based Real-Time Systems

77. 23 Feb. 2007MOTIVES - 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)QoS Management through Adaptive Reservations 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)FSF: A Real-Time Scheduling Architecture Framework 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 Soft Real-Time Systems: Predictability vs. Efficiency,