-*- mode: Text -*- CPU Broker Tim Stack, Eric Eide, John Regehr, Jay Lepreau The Flux Research Group University of Utah http://www.cs.utah.edu/flux/ +1 (801) 585-3271 September 2003 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 quality of service (QoS) needs of "important" applications are satisfied, especially when the relative importance of applications 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 distributed under the GNU General Public License; see the file named `COPYING' for details. PREREQUISITES ------------- autoconf 2.57, automake 1.7.5: Used to generate Makefiles. Java 1.2+: Used to compile helper classes and CORBA interface stubs. LaTeX, dvips, fig2dev (versions?): Used to generate the high-level documentation. gnuplot 3.7: Used to generate graphs for documentation and results for tests. doxygen 1.3: Used to generate documentation from the sources. ACE/TAO 5.3: Provides support for CORBA in C++. Used to facilitate communication between a real-time server and the broker, as well as the different components of the broker. QuO 3.0.11: Provides support for quality of service in CORBA. Used to interpose on a real-time server so as to connect it to the broker. JacORB 1.3.30: Provides support for CORBA in Java. Used to generate stubs so that Java servers can interact with the broker. MIT ATR: Provides an Automatic Target Recognition server. Used as a demonstration of the CPU broker's capabilities. CONFIGURATION ------------- The CPU Broker uses the standard 'configure' utility to adapt to the current host environment. Along with the standard options, the CPU Broker's configure script understands the following: --enable-debug Enable run-time debugging machinery. Highly recommended. --with-ace Specify the ACE installation to use. By default the configure script will use the ACE_ROOT environment variable. --with-quo Specify the QuO installation to use. By default the configure script will use the QUO_ROOT environment variable. This option is only active if ACE is available. --with-jacorb Specify the JacORB installation to use. By default the configure script will use the JACORB_DIR environment variable. This option is only active if ACE is available. --with-atr_mit Specify the ATR install to use. --enable-maintainer-mode Enable 'maintainer mode' for the build tree, where maintainer mode means that the files generated by autoconf/automake will be regenerated during a 'make'. Highly recommended for development environments. BUILDING -------- The programs should build cleanly except for one of the generated files in atr_server/src. The "ATRAdapter.java" file that is created by quogen has some method bodies without prototypes, so you need to delete these before it can finish compiling. TESTING ------- After the system has been built, you can test it by running 'make check'. In addition, there are several targets for gathering and graphing 'experimental' data. XXX These were done in a rush for the demo and should be cleaned up. In the rt_server/src directory: gather1: Runs a single synthetic task with oscillating CPU usage. Note: You can set TASK_FACTORY to change the task factory that will be used (options: 'exact', 'max', 'glacial', 'max_decay'). gather2: Runs three synthetic tasks with constant CPU usage. gather3: Runs two synthetic tasks with oscillating CPU usage. gather4: Runs a single synthetic task with oscillating CPU usage. rt1-graph, rt2-graph, rt3-graph: Post process the output of the gather targets and display the results with gnuplot. In the atr_server/src directory: gather0: Runs trackerStub.jar program from the ATR directory and starts a QuO enabled ATR. The trackerStub.jar name is "ATR_Alert1" and the ATR name is "ATR_1". Note: Unlike the previous targets, you must start the broker, name service, quo kernel, and sender separately. For example: [shell 1] 1 node:atr_server/src> ../../allup/src/broker_allup [shell 2] 1 node:atr_server/src> ../../qosket/basic/cpp/basic_kernel [shell 3] 1 node:release/ImageRec> $TAO_ROOT/orbsvcs/Naming_Service/Naming_Service -ORBEndpoint iiop://localhost:2809 [shell 4] 1 node:atr_server/src> make gather0 "NAME_SERVICE=corbaloc::localhost:2809/NameService" [shell 5] 1 node:release/ImageRec> /usr/java/j2sdk1.4.1_02/bin/java -DORBInitRef.NameService=corbaloc::localhost:2809/NameService -jar receiverStub.jar GUI.jar tank.gz 533 1 ATR_1 placeholder [Finally, when the ATR has run for long enough, kill everything and run the following to generate a graph] 2 node:atr_server/src> make atr-graph INSTALLATION ------------ Once you are satisfied that the broker is working correctly, you can install everything using: $ sudo make install The installation directory is determined by the value of the '--prefix' option as passed to configure, with the default being '/usr/local/cpu-broker'. We also provide some scripts for adding the broker's binaries, manuals, and libraries automatically added to every users paths. To activate them you simply create links in the system's '/etc/profile.d' directory to the files in the broker's 'etc/profile.d' directory, like so: $ sudo ln -s /usr/local/cpu-broker/etc/profile.d/* /etc/profile.d/ After logging out and back in, you should now be able to access the broker's files easily, for example: $ man rktimes ... FILES ----- See the MANIFEST file in the current directory. HISTORY ------- September 2, 2003: Updated for 0.5 release. June 12, 2003: Initial revision.