Elastic Task Model for Adaptive Rate Control: Enhancing Real-Time Task Flexibility

1. Elastic Task Model for Adaptive Rate Control Giorgio Buttazzo, Giuseppe Lipari, Luca Abeni, Elastic Task Model For Adaptive Rate Control, RTSS 1998.

2. Outline • Introduction • Elastic Model • Compressing Task Utilization • Theoretical Validation • Experimental Results • Conclusions Introduction

3. Motivation • Classic real-time task models are too rigid • For a task i is defined by constant period Ti & exec time Ci in RM & EDF • Schedulability guarantee • Necessary for stability of critical hard real-time systems Introduction

4. Motivation • More flexibility is required by multimedia & adaptive control applications • MPEG encoding/decoding time may vary from frame to frame • A deadline miss can degrade QoS but doesn’t cause any catastrophic result • Considering as hard real-time task is too pessimistic • Underutilize the CPU as WCET >> average exec time Introduction

5. Elastic Task Model (ETM) • Treat task periods as springs with given elastic coefficients • Increase/decrease task periods to control QoS considering the current load • Allow tasks to intentionally change their execution rates to provide different levels of QoS • Handle overload situations in a more flexible way Introduction

6. Imprecise computation, (m,k) firm deadlines, and ETM: Which is best? • Review • Imprecise computation can reduce task exec time by skipping (or spending fewer CPU cycles for) optional parts • (m,k) model can drop jobs, i.e., task instances, in a controlled manner • Which is best? Always out perform the others? We don’t know. Introduction

7. Imprecise computation, (m,k) firm deadlines, and ETM: Which is best? • One model may not work best for every application • For even one application, e.g., video streaming, one or the other may show better performance under certain circumstances • Which model work best in certain situations? • This can be a good course proejct topic (More topics at the end of the talk) • Can we develop any model that outperforms these models (in even some specific application)? Introduction

8. Outline • Introduction • The Elastic Model • Compressing Task Utilization • Theoretical Validation • Experimental Results • Conclusions The Elastic Model

9. Task Parameters • Computation time Ci (fixed) • Nominal period Ti0 • Minimum period Timin • Maximum period Timax • Elastic coefficient ei >= 0 • A task = i(Ci, Ti0, Timin, Timax, ei) The Elastic Model

10. Parameter Constraints • Ti: actual period of task i • Ti [Timin, Timax] • Any variation is subject to an elastic guarantee and is accepted only if there exists a feasible schedule in which all the other periods are within their range The Elastic Model

11. Schedulable by EDF • Up= 10/20 + 10/40 + 15/70 = 0.964 < 1 • 3 reduces its period to 50 • Up= 10/20 + 10/40 + 15/50 = 1.05 > 1 • Not schedulable • Change T1 to 22 and T2 to 45 • Up= 0.977 • Schedulable! The Elastic Model

12. Example Cont. • 3 reduces its period to 40 • Schedulable • T1 = 35 must be rejected, since there’s no feasible schedule with T1 and T2 within their (min, max) period ranges The Elastic Model

13. Configuration Policy • Implicitly encoded in the elastic coefficients provided by the user • Each task is varied based on its current elastic status under the condition that a feasible configuration is found (if there exists one) The Elastic Model

14. More Features • The other direction (decompressoin): Task terminates or decreases its rate. • Other tasks gain back bandwidth – Increase their rates, if necessary, to improve QoS • Hard real-time tasks • Ti0= Timin = Timax The Elastic Model

15. Outline • Introduction • The Elastic Model • Compressing Task Utilization • Theoretical Validation of the Model • Experimental Results • Conclusions Compressing Tasks’ Utilizations

16. Compressing Task Utilization • Set of periodic task Γ can be divided into: • Γf: Set of fixed tasks in which an arbitrary task i in the set consumes it minimum utilization, i.e., its current period Tf = Tfmin • Γv: Set of variable tasks that can be still compressed • For task v in Γv its current period Tv > Tvmin • Period can be increased to reduce utilizaiton • U0: Sum of all the nominal utilization (Ci/ Ti0) for the tasks in Γv • Uf: Total utilization of the tasks in Γf Compressing Tasks’ Utilizations

17. Compressing Task Utilization • To achieve the desired utilization Ud < U0, each task in Γv has to be compressed to the following utilization: Introduction

18. Compressing Tasks’ Utilizations

19. Decompression • A task decreases its rate or returns to its nominal period • Compressed tasks expand their utilizations according to their elastic coefficients • If total utilization is less than utilization bound, then all tasks can return to their nominal periods Compressing Tasks’ Utilizations

20. Outline • Introduction • The Elastic Model • Equivalence with a Spring System • Compressing Tasks’ Utilizations • Theoretical Validation of the Model • Experimental Results • Conclusions Theoretical Validation of the Model

21. Theoretical Validation: Key Idea • If tasks’ periods are changed at opportune instants, the task set remains schedulable and no deadline is missed → Find out when is the opportune time!!! • The following lemmas state two properties of the EDF algorithm that are useful for proving the main theorem Theoretical Validation of the Model

22. Lemma 1 • In any feasible EDF schedule , the following condition holds: • t >0  i[1,n] ri(t)/t >= Up • Where Up =  i[1,n] Ci/ Ti and ri(t) is the cumulative time executed by all the instances of task i up to t • Processor demand analysis Theoretical Validation of the Model

23. Lemma 2 • In any feasible EDF schedule , the following condition holds: • t >0 i[1,n] ci(t) ≤  i[1,n] [vi(t) – t]Ui • Where Ui = Ci/ Ti, ci(t) is the remaining execution time of the current instance of task i at time t, and vi(t) is the next release time of i greater than or equal to t Theoretical Validation of the Model

24. Theorem 1 • Given a feasible task set Γ, with total utilization factor Up =  i[1,n] Ci/Ti ≤ 1, if at time t all the periods are increased from Ti to T’i ≥ Ti, then for all L > 0, • D(t, t+L) ≤ LU’ p • Where D(t1, t2) is the total processor demand of Γ in [t1, t2] and U’p =  i[1,n] Ci/T’i Theoretical Validation of the Model

25. What does the theorem mean? • Periods can be increased immediately, but • The period of a task can be decreased only at its next release time • Example in the next slide Theoretical Validation of the Model

26. Orignally, 3/10 + 2/3 = 0.96 < 1 After changing periods at t =14: 3/5 + 2/6 = 0.96 If T1 is immediately changed at t = 14, D miss at t = 16 D Miss! Theoretical Validation of the Model

27. Outline • Introduction • The Elastic Model • Equivalence with a Spring System • Compressing Tasks’ Utilizations • Theoretical Validation of the Model • Experimental Results • Conclusions Experimental Results

28. Experimental Results

29. Experimental Results

30. Experimental Results

31. Experimental Results

32. Outline • Introduction • The Elastic Model • Equivalence with a Spring System • Compressing Tasks’ Utilizations • Theoretical Validation of the Model • Experimental Results • Conclusions Conclusions

33. Conclusions • Periodic tasks can change their execution rates to adapt QoS • Remaining tasks can canautomatically adapt their peroids to keep the system underloaded • Policy is encoded in the elastic coefficient • Useful for supporting both multimedia and adaptive control applications, in which the execution rates of some computational activities have to be dynamically tuned as a function of the current system Conclusions

34. Single Semester-Long Prject vs. Programming Assignments • Students can work in teams for projects • Programming assignments are individual – No teamwork is allowed • 1st programming assignment will be available in this week • If it’s your first time to real-time emebedded systems or your are under pressure, it will be safer to do programming assignments • If you are interested in RT research, do a project • Pick a topic among the ones to be discussed today (or identify your own topic), find a team if possible, and discuss with me Introduction

35. Single Semester-Long Prject vs. Programming Assignments • Decide whether you will do a project or programmingassignments by Sept 26 and let the TA and me know about your decision • If you are doing a project, let the TA and me knwo about your topic, team members, etc. Introduction

36. Project Idea 1 • Verify if real-time scheduling theory, e.g., RM, EDF, priority inheritance/ceiling, really works • Tweak a RT kernel in your way to improve schedulability, reduce overhead/kernel complexity, or make it more configurable... • Some open source real-time embedded kernels are in the next slide Introduction

37. Prject Idea 1 • Open source RT/embedded kernels • eCos (embedded configurable OS) • Open source, royalty-free RTOS • Can be installed in Linux or Windows (with Cygwin) • Highly configurable – How does configurability make a RTOS better? Performance optimization & memory footprint minimization • http://ecos.sourceware.org/ • uc/OS-II • Commercial, open-source RT kernel • Easy to use and runs in Windows environment • http://www.ucos-ii.com/products/rtos/kernel/rtos.html • Book:http://www.amazon.com/MicroC-OS-II-Kernel-CD-ROM/dp/1578201039 • L4 Kernel • http://l4ka.org/projects/pistachio/ia32/gettingstarted.php Introduction

38. Project Idea 2 • Compare imprecise computation model, (m,k) firm deadline model & ETM for a multimedia application • Qualitative analysis: Which is more applicable? Why? • Experiments to support your arguments • DSRT: Dynamic Soft Real Time CPU Scheduler 2.0 • http://cairo.cs.uiuc.edu/software/DSRT-2/dsrt-2.html • Middleware that works with either Windows or Linux Introduction

39. Project Idea 3: Real-Time Database • We have a home-made simulator written in C++ • We also have a preliminary version of a testbed implemented on top of an open source DB called Berkeley DB • Choose to do a simulation or real DB implementation • 1. Make the home-made simulator or testbed more structured/easier-to-use or make one of them to support distributed RT transaction processing; OR • 2. Make the RTDB testbed to interact with wireless sensors; OR • 3. How to handle RTDB specific issues such as data freshness or data conflicts properly, while supporting timing guarantees?; Introduction

40. Project Idea 4 • Power-aware real-time routing • Shortest path to minimize the delay • No need for a packet to arrive at the destination earlier than the deadline • Take an alternate path to reduce power consumption given enough slack – Just-in-time scheduling + power management • You can use network simulation in ns-2 Introduction

41. Project Idea 5 • Differentiated real-time routing • Initially assign a deadline for a packet based on distance or number of hops • Define the criticality for each periodic data flow • Criticality could be indicated by an elastic cofficient such that less critical flows are more elastic • Schedule packets in an EDF manner • When a router is backlogged, adapt the deadlines of elastic packets (according to the elasticity constraints) • Piggyback the adaptation info as part of ACK message • Eventually propagate to the source • Forward less urgenet packets through an alternate path • Network simulation via ns-2 Introduction

42. Project Idea 6 • Remote control of robots on Mars (simulation) • You can find the problem description and simulator here! Introduction

43. Any Questions? Introduction