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: