Allegro...

...will become a light-weight distributed run-time environment for heterogeneous clusters, considering QoS guarantees and easy customisation even at run time. At its heart will be a predictable bare-bones object request broker with only the absolutely necessary bells and whistles. Higher level (service-dependent) functionality such as caching or varying consistency models among multiple copies of an object will be handled by smart proxies only. Further issues to be considered at this level are heuristics that allow for advanced admission tests, taking object migration into account, for example. Such an architecture offers transparency at the service level to those satisfied with the default behaviour while making allowance for far-reaching modifications from a developer that needs more complete control over caching or consistency policies, for instance.

Additionally, Allegro will integrate an open user-level real-time threads package called CoolJazz, which is an object-oriented successor of FreeJazz.

Beat

To support distributed real-time applications an operating system needs to be able to schedule and reserve the use of resources such as CPU time and network bandwidth. POSIX.1b compliant systems provide priority-based CPU scheduling policies, which can be used as a basis for advanced resource management mechanisms. For network transmission, however, usually there is no such feature.

In the first stage of Beat (Basic rEAl-time Transmission), we have added basic real-time mechanisms on top an Ethernet to the Linux operating system while not precluding the use of conventional applications and protocols such as TCP and UDP. This service can be used as a basis for a dynamic soft real-time system.

To avoid the indeterminism of the CSMA/CD network access control a token mechanism has been employed. Priorities can be attached to packets and are taken into account in allocating bandwidth locally, for the messages on the node, as well as globally, among the nodes on the network. Moreover, shares of network bandwidth can be reserved by tasks, controlled by a utilization-based admission test. In addition, a global notion of time is needed for time constraints to be meaningful in a distributed real-time system. It is provided by a clock synchronization algorithm that has been integrated with the communication mechanisms. By directly accessing low-level packet transmission an accuracy in the order of 10 us is achieved. The BEAT communication service introduces an overhead of about 10% for processing time as well as for network bandwidth.

Next, we are going to implement Beat as a communication server running on Linux as well as on the real-time operating system LynxOS. While this version will not work together with conventional protocols any more, it will allow to compare performance between Linux and LynxOS as well as between the kernel and the server implementation.

Fortissimo

The correctness of real-time systems does not only depend on the logical result of the computation but also on the time at which these results become available. Thus, to cope with these stringent requirements, complex real-time systems demand for sophisticated scheduling algorithms that coordinate multiple activities according to their time constraints. Optimal real-time scheduling, however, easily imposes unacceptable run-time overhead or even becomes computationally intractable at all, particularly in the case of multiprocessors or distributed systems. As always, if exact solutions are ruled out, heuristics set in. Profound analysis of heuristics, however, generally relies on simulation prior to real-world tests. As part of the necessary groundwork to derive taylor-made heuristics for Squirrel, we are developing a real-time scheduling simulator called Fortissimo.

Currently, Fortissimo allows for soft, firm, and hard deadlines as well as value-function scheduling in uniprocessor and multiprocessor environments with support for distributed systems coming soon. Scheduling algorithms that may be easily implemented within Fortissimo include fixed-priority and dynamic-priority assignment policies, aperiodic servers (e.g., deferrable server, sporadic server), imprecise and task-pair scheduling, and skip-over algorithms. Simulation runs may be statistically varied with regard to task periods, worst-case computation times and the execution time needed by a singular invocation of a periodic tasks, and the arrival rate of aperiodic and sporadic tasks.

FREE JAZZ...

...is an open user-level real-time threads package, developed as part of the infrastructure needed for Squirrel. Beside being small and fast, one of the main objectives was high flexibility. In fact, no single user-level threads packages has gained wide popularity among designers of multi-threaded run-time systems by now due to a number of restrictions ultimately bound to their black-box approach. This is particularly true when it comes to scheduling decisions that are usually tightly interweaved with the core of each thread package. Consequently, we decided to completely untangle scheduling from dispatching and to provide a meta interface instead. The scheduler consists of user-supplied components that merely react to system-defined as well as user-defined events. Further, the policy of all internal queues may be overridden by the user and a free-form constraint field allows for providing any information that may be relevant to scheduling decisions and queueing strategies.

Right now we are developing an object-oriented successor called CoolJazz that will become an integral part of Allegro.

Infopipes

Building applications that process information flows on existing middleware platforms is difficult, because of flow-specific concurrency and timing requirements, the need for application-specific protocols, and the poor match of the commonly used abstraction of remote invocations to streaming. In collaboration with the Systems Software Lab at the Oregon Graduate Institute we are developing a middleware platform for information flow applications based on the Infopipe abstraction. Infopipes handle complexities associated with control flow and multi-threading transparently. The ability to query individual Infopipe elements as well as composite Infopipes for properties of supported flows enables QoS-aware configuration. Similarly to local protocol frameworks Infopipes provide a flexible infrastructure for configuring communication services from modules, but unlike protocols the abstraction uniformly includes the entire pipeline from source to sink, possibly across process and node boundaries.