Utah CPU Broker, Version 1.0.0
------------------------------
The Flux Research Group at the University of Utah announces a new
release of the Utah CPU Broker, version 1.0.0. This release includes
an improved contention policy whose behavior is less erratic when
dealing with tasks of the same priority, more documentation, an
in-depth tutorial, a single all-encompassing server that replaces the
individual object servers in the previous version, a single
all-encompassing client that replaces the individual command-line
clients in the previous version, automatic repair of state when some
objects become unreachable, an improved build system, more test cases,
and the usual bug fixes.
Download the CPU Broker software, documentation, and papers at:
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: