1. QoS-based Management of Multiple Shared Resources in Dynamic Real-Time Systems Klaus Ecker, Frank Drews School of EECS, Ohio University, Athens, OH {ecker, drews}@ohio.edu

2. Overview of the Talk Introduction Feedback-control based resource management architecture Heuristics for allocating multiple resources to soft real-time tasks Results –Simulation results Outlook and future work

3. Introduction Problem of adaptive resource management with soft real-time tasks –sharing multiple resources –having discrete QoS (Quality of Service) settings that correspond to varying resource usage and varying user benefit (utility) –having minimum QoS requirements –being deployed in a mixed critical system –integrated into a feedback-control based resource management architecture

4. Real-time Design and Development Traditional design: –often pessimistic... –use worst-case execution times of tasks guaranteeing provably correct timeliness e.g., rate monotonic analysis –infrequent critical instants, –inaccurate resource profiles, etc.... may lead to poor performance

5. Soft Real-Time Tasks Allow Alternative Approaches System resource usage is controlled by modifying QoS parameters Objective: maximize overall system benefit –E.g., multimedia applications: quality of service depends on the amount of resources for the individual tasks Our system model is similar to Q-RAM –Q-RAM MCMDKP (Multiple Choice Multidimensional Knapsack Problem) –Static Optimization Problem No notion of run-time variations

6. Additional requirements We associate 2 profiles with each task –Resource profile:maps QoS to resources –Utility profile: maps resources to system benefit Resource availability may change over time –Resource profiles are inherently inaccurate –We may only allocate a fraction of resources to the soft real-time tasks Requires run-time resource reallocations A good static resource management algorithm may result in instability in the presence of run-time variations in resource availabilities Resource reallocations based on feedback control

7. Motivation / Background Mixed critical task systems: Soft real-time tasks may be periodic, aperiodic, or event-driven periodic We may want to allocate a share of available resources to soft real-time tasks –may change over time Resource profiles may be inaccurate

8. Feedback-control Architecture set point ( 100%- desired slack) measured resource availability (feedback) Error QoS RM Controller QoS settings Resource allocation algorithm

9. Basic Controller Operation Controller is event-driven. It is driven by the following events: –End of a task period –Task arrival –Task termination The controller computes the error and calls the QoS resource allocation algorithm This algorithm determines new QoS settings for all tasks

10. Controller Requirements Basic QoS controller requirements: –Robustness with respect to modeling errors, i.e., inaccurate resource profiles –Stability with respect to dynamic changes in the resource availability The system should not exhibit a cyclic behavior Errors should not accumulate –Low time complexity –Upper and lower bounds on the optimal solution can be used to characterize the QoS control performance

11. Observations We generally expect the controller to minimize the control error Observation 1 If the tasks QoS settings are discrete and concave, minimizing is not sufficient for maximizing the overall system benefit

12. Notation The model: The model: different resource types each of them available in several units The non- soft r.-t. tasks require some share of the available resources, which may vary over time Unused resources at current time: units of The soft r.-t. tasks –compete for these, –their performance depends on the amount of allocated resources. Performance of a task … depends on the type and number of assigned resources

13. Objective Objective: The resource units are to be distributed (allocated) among the soft r.-t. tasks such that QoS is maximized Assumption: Utility (Performance) of a task is discrete and concave Concave utility functions are widely used in this area Examples of utility measures: Inverse of processing time: the more resources a task has, the shorter the processing time, and the higher the benefit. Precision of computation: more resources lead to better computational results.

14. The total utility of an allocation is defined as: Optimization Problem (formally): Given minimal resource constraints, find resource values for each such that is maximum, subject to for MCMDKP Multiple Choice Multidimensional Knapsack Problem

15. Algorithmic Approaches Algorithms apply Kuhn-Tucker theorem adaptation to discrete functions : Rajkumar et al., 1997: The discrete problem is NP-complete in the case of one resource type Judd et al., 2005: Feedback-control framework; Algorithm with bounds on optimal solution and prove for control stability It can be solved in polynomial time in case of unit step functions Discrete_Kuhn_Tucker ( DKT ) algorithm (steepest ascent rule) Single resource type:

16. In case of concave functions the discrete problem is NP complete, even in case of unit step utility functions Proof: Reduction from the Maximum Packing Integer Programming Problem Case of m 2 resource types:

17. Chen Lee et al., 1999: a linear programming algorithm for unit resource allocation steps and non-concave functions Complexity pseudo-polynomial time and space complexity not appropriate for on-line resource management with large Case of m 2 resource types:

18. Multidimensional Kuhn-Tucker Algorithm Applies to the resource directions in some chosen order, say. Properties of MDKT: –time complexity is linear in the number of tasks, n –not optimal in general Algorithm Multidimensional_Discrete_Kuhn_Tucker (MDKT) for i := 1 to m do DKT()

19. Alternative heuristics: Steepest_Ascent allocates the excess resources unit by unit such that, at each step, the total utility is increased by the maximum possible amount. Properties of STAS: –time complexity is linear in the number of tasks n –not optimal in general Algorithm Steepest_Ascent (STAS) repeat choose a task and an available resource such that is maximum; assign one unit of to ; until all resource units are allocated;

20. Estimating Lower and Upper Bounds Special "uniform" utility functions : ai, bi... utility increase by adding one resource unit MDKT is optimal for uniform utility functions

21. General utility functions : Non-trivial lower and upper bounds on can easily be found Replace each by uniform functions and that are close to the original functions Then:

22. Simulations for the case of resource types Utility function were generated in two different ways: (a)Directly using random numbers from the interval [0,100] (b)By evaluating the function Where the parameters were chosen arbitrarily between 0 and 200.

23. Sample Utility Function

24. Results The lower and upper bounds for are approx 10% apart. Experimental studies also show that performed on average on order or magnitude better than We performed simulations with fixed task numbers between 2 and 35, and resource units between 2 and 100. In each case we performed 10000 tests.

25. Performance of MDKT and STAS against the optimum, for varying task numbers between 5 and 35 : In average, the utility of the MDKT-solutions is less than 0.3 % below the optimum

26. The next simulation compares MDKT and STAS for 5 tasks and varying numbers of resource units There are up to 15 units of each resource available More resource units lead to better performance of MDKT. Again there is no significant deviation of STAS from the optimum.

28. Dynamic Changes of Resource Availability If resource units are withdrawn from soft real-time tasks then one or more tasks have to run at a lower utility, thus resulting in a smaller total system utility. If available resource units increase the tasks should take advantage in order to increase their contribution to the total system utility.

29. General Strategy If one of the resource limits is reduced by one unit, reduce the assignment of this resource for a task that has minimum loss of utility. If one of the resource limits is increased by one unit, then assign the additional unit to a task that offers maximum utility gain. Simulation studies show that the system behaves stable.

30. Conclusions Extending the work of QRAM, we have presented heuristics to optimize utility with respect to QoS settings. The heuristics are efficient and stable control algorithms optimize task QoS settings within known margins, do not accumulate errors over time

31. Future Work