1. Utility-Function based Resource Allocation for Adaptable Applications in Dynamic, Distributed Real-Time Systems
Presenter: David Fleeman { }
F. Drews, L. Welch, D. Juedes and D. Fleeman
Center for Intelligent, Distributed & Dependable Systems
Ohio University
Athens, OH
WPDRTS 2004
April 26, 2004

2. Overview Simplistic model for resource (re)-allocation algorithms.
Formalization of a multi-criterion optimization problem.
Service Attributes
Extrinsic Attributes
Simple hierarchical architecture that supports the algorithm.
How it would fit into the QARMA architecture.
WPDRTS, April 26, 2004

3. Common real-time engineering approaches
Use “worst-case” execution times to characterize workloads a priori.
Allocate computing and network resources to processes at design time.
Problems:
Limits the functionality and flexibility of applications to adapt to new situations.
Limits the options to handle overloading of system resources.
May lead to poor resource utilization.
Inappropriate for applications that must execute in highly dynamic environments.
WPDRTS, April 26, 2004

4. How to react in response to environmental changes?
1. Reallocation approach
Dynamically reconfiguring the way in which computing and network resources are allocated to processes
2. Service level and utility approach
Simple strategy: assigning fewer resources by slowing applications down (first few versions of BBN UAV OEP).
More advanced strategy: utility function and service levels
WPDRTS, April 26, 2004

5. Service levels and Utility function Approach
Defined as the “user perceived benefit by performing a certain action with a particular fidelity within the given time constraints”.
Function that describes the quality of the output of an application depending on the service level.
Specified by the user.
Utility
1.0
0.8
0.3
0.1
Service Level (compression)
none
lossless1
lossless2
lossy1
WPDRTS, April 26, 2004

6. Our approach
Most existing approaches are based on either reallocation of resources or adaptation of service levels in response to dynamic changes in the environment without a notion of system utility.
Our approach combines the dynamic reallocation and the service level with the goal of optimizing system utility.
Similar work
Q-RAM from CMU
Dr. Jensen’s work in TUF and UA
WPDRTS, April 26, 2004

7. Definition of the System Model
Hardware components
Set of hosts: Each host specified by
memory size, SPEC rates, etc.
Interconnection Network
WPDRTS, April 26, 2004

8. Definition of the System Model
Software components:
Application software system:
Logical view that distinguishes several layers of abstraction:
Highest level: Total system
Next lower level: Collection of subsystems
A subsystem is a collection of paths, each with a given period or maximum event-rate
Path consists of a set of tasks (or applications) and data-depedencies between tasks
WPDRTS, April 26, 2004

9. Definition of the System Model
Software components
Set of tasks:
Each task specified by
execution time profiles and memory profiles:
depending on the processor is assigned to
depending on certain operational conditions set by the environment (“extrinsic attributes”)
depending on certain parameters that can be changed at runtime (“ service level attributes”)
periodic applications: period
event-driven applications: maximum event rate modelled by
WPDRTS, April 26, 2004

10. Definition of Extrinsic Attributes
Express functional conditions or requirements
Determined by environmental conditions
Determined by status of system components.
Set by external conditions and cannot be changed by the system
Examples:
event-rate of event-driven tasks
workload
WPDRTS, April 26, 2004

11. Definition of Service Attributes
Can be changed at any time by resource manager
If external conditions change, appropriate settings of the service attributes allow adaptation to the new conditions
Examples:
Compression algorithm or type
Pixel processing parameters
WPDRTS, April 26, 2004

12. Utility Functions
For local optimization, each subsystem is provided a local utility function that measures the contribution of subsystem to the overall system utility
represents the maximum manageable extrinsic attibutes
The (overall) system utility function can be computed from the subsystem utilities by means of some aggregation function:
Example:
WPDRTS, April 26, 2004

13. Optimization Objective
Find an allocation of applications to hosts
and settings of service attributes and settings of maximum
manageable extrinsic attributes such that
The allocation is feasible (i.e., runtime conditions and memory limitations on the hosts are satisfied. That is, all the applications meet their deadlines)
The overall system utility is maximum
The values of the maximum manageable extrinsic attributes are as high as possible
WPDRTS, April 26, 2004

14. Service Table
Ideas:
Using a table look-up technique for the resource manager.
Restrict the problem to discrete grid points.
RM is provided with a table containing “good candidate solutions”,i.e., allocations along with service attribute settings and (maximum) manageable extrinsic attributes that are computed during a pre-runtime analysis.
Service table:
WPDRTS, April 26, 2004

15. Simple Example 6 5 4 3 2 1 1 2 3 4 5 6
WPDRTS, April 26, 2004

16. Hierarchical Architecture of an Adaptive Resource Manager
Main Objectives:
Reflect the logical decomposition into subsystems, paths, and applications
Scalability: Remove or reduce the bottleneck of a central resource manager
Main Assumption:
Task migration is more expensive than modification of service level parameters
WPDRTS, April 26, 2004

17. HierarchicalArchitecture of an Adaptive Resource Manager
Dynamic Reallocation
Chooses allocation from ST
Overall System Utility Optimization
Receive sub-table from AM
Local Utility Optimization by means of Service Level Modification
WPDRTS, April 26, 2004

18. Generic Resource Management Architecture
Configuration
Files
Detectors
Decision-Maker
Monitors
Information
Repository
Enactors
Environment
Resource Instrumentation
Software Instrumentation
Resource and Software
Management Commands
Computing Environment &
User Applications
WPDRTS, April 26, 2004

19. CORBA Resource Management Architecture
QARMA Components
Specification
Tool
Configuration
Files
System Repository Service
Resource Management Service
Enactor
Service
Replaceable Components
Host and Network
Monitor / Detector
Software Performance Monitor / Detector
Enactor
(Quality Connector)
Hosts/Networks
Host and Network
Monitor / Detector
Software Performance Monitor / Detector
Enactor
(Quality Connector)
Host and Network
Monitor / Detector
Software Performance Monitor / Detector
Enactor
(Quality Connector)
Resource Management Service Goal
Each chain of applications achieves a “benefit” based on it’s service attribute settings (e.g., frame rate) and extrinsic attribute settings (e.g., importance).
The Resource Management Service changes service attributes in order to optimize total benefit, subject to the constraint that all tasks meet their real-time requirements.
UAV Video
ATR
Tracking
Application Layer (independent of QoS mechanism)
WPDRTS, April 26, 2004

20. Integration of Approach in QARMA
Resource Management Architecture
QARMA Components
Specification
Tool
Configuration
Files
System Repository Service
Allocation
Manager
Enactor
Service
Replaceable Components
Global Service Optimizer
Host and Network
Monitor / Detector
Enactor
(Quality Connector)
Hosts/Networks
Host and Network
Monitor / Detector
Enactor
(Quality Connector)
Host and Network
Monitor / Detector
Enactor
(Quality Connector)
Local Service Optimizer 1
Local Service Optimizer 1
Local Service Optimizer 1
UAV Video
ATR
Tracking
Application Layer (independent of QoS mechanism)
WPDRTS, April 26, 2004

21. Contribution of this paper
Lays the basis for further work on online and offline resource allocation algorithms.
Provides a general optimization model and an architecture for dynamic, distributed real-time systems.
Introduces hierarchical decision-making architecture.
Shows how it can (will) be implemented in a real resource management system.
WPDRTS, April 26, 2004