Utah CPU Broker, Version 1.1.0
------------------------------
The Flux Research Group at the University of Utah announces a new release of
the Utah CPU Broker, version 1.1.0. The new features in this release include a
proportional share contention policy, a meta-policy for partitioning tasks
among sub-policies, an "observer" advocate that automatically makes reports and
can be located in the main broker process, and changes to the advocate
interface so that tasks can dynamically adjust their periods in addition to
their compute times. In addition, this new release contains more test cases,
expanded documentation, and the usual variety bug fixes.
Download the CPU Broker software, documentation, and papers at:
Our recent RTAS 2004 paper describes and evaluates the CPU Broker in detail:
The CPU Broker is a reservation-based resource manager for CPU time. The
broker mediates between multiple real-time applications and the facilities of
an underlying real-time operating system: it implements a configurable CPU
management policy, monitors resource use, and adjusts allocations over time.
This architecture helps to ensure that the QoS needs of "important" tasks are
satisfied, especially when the relative importance of various tasks changes
dynamically. An additional and important benefit is that the broker can
automatically determine many of the scheduling parameters of its client
applications.
The CPU Broker is implemented as a CORBA server that uses the TimeSys Linux
resource kernel APIs to manage CPU reservations.
The CPU Broker is currently being applied to BBN's Unmanned Aerial Vehicle
(UAV) OEP .
The broker enables dynamic adaptation and reallocation of CPU resources for UAV
deployments: such adaptation is required in response to the changing importance
of various information flows (e.g., the identification of time-critical
targets), changing battlefield conditions (e.g., assets and asset status),
changing mission modes, and/or changing missions. The broker supports feedback
and configurable strategy-based policies for adaptation and handling
conflicting reservations. These strategies can be driven or implemented by
other QoS-enabling middleware, such as QuO, and integrated with other resource
management facilities (e.g., network reservations and application-level
adaptation strategies) as part of an overall end-to-end QoS management
solution.
Please send bug reports, questions, and comments to: