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: