Resume

System Time

Location:

Boulder, CO

Posted:

January 22, 2013

Contact this candidate

Resume:

Con guring Real-time Aspects in Component

Middleware

Nanbor Wang1, Christopher Gill2, Venkita Subramonian2, and Douglas C.

Schmidt3

Tech-X Corp, Boulder, CO

abqf2b@r.postjobfree.com

Distributed Object Computing Group, Washington University, St. Louis

fcdgill, abqf2b@r.postjobfree.com

Institute for Software Integrated Systems, Vanderbilt University, Nashville

abqf2b@r.postjobfree.com

Abstract. This paper makes two contributions to the study of con g-

uring real-time aspects into quality of service QoS -enabled component

middleware and distributed real-time and embedded DRE systems. First,

it compares and contrasts the integration of real-time aspects into DRE

systems using conventional QoS-enabled distributed object computing DOC

middleware versus QoS-enabled component middleware. Second, it presents

experiments that evaluate several real-time aspects con gured in The ACE

ORB TAO versus in the Component-Integrated ACE ORB CIAO .

Our results show that QoS-enabled component middleware implementa-

tions can o er real-time performance that is comparable to DOC middle-

ware, while o ering greater exibility in composing and con guring key

DRE system aspects.

Keywords. Real-time aspects, Component middleware, Real-time CORBA, CORBA

Component Model.

1 Introduction

Developers of complex distributed real-time and embedded DRE systems need

middleware technologies that o er 1 explicit con gurability of policies and

mechanisms for systemic aspects, such as real-time quality of service QoS , so

that developers can meet the stringent QoS requirements of modern DRE sys-

tems and 2 a programming model that explicitly separates systemic aspects

from application functionality so developers can untangle code that manages

systemic and functional aspects, resulting in systems that are less brittle and

costly to develop, maintain, and extend. This section rst describes how conven-

tional real-time distributed object computing DOC middleware and compo-

nent middleware technologies each provide one of these requisite capabilities, but

not the other. We then describe our approach, which integrates con gurability

of real-time DOC middleware within a standards-based component middleware

programming model.

Limitations with existing middleware technologies. Component middleware 1

technologies are an emerging paradigm that provides mechanisms to con gure

and control key distributed computing aspects, such as connecting event sources

to event sinks and managing transactional behavior, separate from the functional

aspects of the application. Conventional component middleware platforms, such

as the Java 2 Enterprise Edition J2EE and the CORBA Component Model

CCM , are designed to address the QoS needs of enterprise application do-

mains such as work ow processing, inventory management, and accounting sys-

tems , which focus largely on scalability and transactional dependability. Other

domains, however, require additional constraints to meet application require-

ments, e.g., over 99 of all microprocessors are now used for DRE systems 2

that control processes and devices in physical, chemical, biological, or defense

industries.

Examples of DRE systems include distributed sensor networks, ight avion-

ics systems, naval combat management systems, and nancial trading systems,

which have stringent QoS requirements. In these types of systems the right an-

swer delivered too late becomes the wrong answer, i.e., failure to meet QoS

requirements can lead to catastrophic consequences. Research over the past

decade 3 5 has shown that the coordinated management of application and

system resources is essential to ensure QoS. Conventional component middle-

ware, however, does not provide adequate abstractions to control the mecha-

nisms for managing these behaviors and thus is not suitable for applications in

these domains.

Since the time e ort required to develop and validate DRE systems pre-

cludes developers from implementing these systems from scratch, attempts have

been made to extend standard middleware speci cations so they provide better

abstractions for controlling and managing domain-speci c aspects. For example,

Real-time CORBA 1.x 6 which is part of the DOC middleware CORBA 2.x

speci cation 7 introduces QoS-enabled extensions that allow DRE systems

to con gure and control 1 processor resources via thread pools, priority

mechanisms, intra-process mutexes, and a global scheduling service for real-time

applications with xed priorities, 2 communication resources via protocol prop-

erties and explicit bindings to server objects using priority bands and private

connections, and 3 memory resources via bu ering requests in queues and

bounding the size of thread pools.

Although CORBA 2.x provides mechanisms to con gure and control resource

allocations of the underlying endsystem to meet real-time requirements, it lacks

the exible higher level abstractions that component middleware provides to

separate real-time policy con gurations from application functionality. Manu-

ally integrating real-time aspects within CORBA 2.x application code is there-

fore unduly time consuming, tedious, and error-prone 8 . It is therefore hard

for developers to con gure, validate, modify, and evolve complex DRE systems

consistently using QoS-enabled DOC middleware, such as CORBA 2.x and Real-

time CORBA.

Solution approach ! Integrating real-time QoS aspects into component middle-

ware. To resolve the limitations with the status quo described above, we are

integrating 1 component middleware, which enables behavioral aspects to be

speci ed declaratively and woven into application functionality automatically

rather than programmed imperatively by hand with 2 QoS-enabled DOC

middleware, which supports end-to-end QoS speci cation and enforcement, to

create QoS-enabled component middleware. Successful integration of these two

approaches requires the resolution of the following challenges:

The component middleware's con guration infrastructure must be extended

to incorporate speci cation interfaces, tunable policies, and enforcement

mechanisms for real-time aspects and

The performance and predictability of the resulting QoS-enabled component

middleware's runtime environment must be validated empirically to ensure

it supports the desired real-time properties end-to-end.

This paper extends our prior work 9, 10 by comparing the complexity of

programming CORBA 2.x DOC middleware features directly in the ACE ORB

TAO 11 which implements the CORBA 2.x DOC middleware standard in-

cluding Real-time CORBA versus con guring them via component middleware

features in the context of the Component-Integrated ACE ORB CIAO 10

which is a QoS-enabled implementation of CORBA 3.x CCM speci cation im-

plemented atop TAO .4 It also presents experiments that compare the real-time

performance of an example DRE system implemented in TAO and CIAO. Our

results show that QoS-enabled component middleware implementations can o er

performance and predictability similar to that of real-time DOC ORB middle-

ware, while improving exibility to compose and con gure key DRE system QoS

aspects.

Paper organization. The remainder of this paper is organized as follows: Sec-

tion 2 illustrates how our work on CIAO overcomes limitations with earlier work

on component and DOC middleware; Section 3 presents experiments comparing

TAO and CIAO's real-time performance; Section 4 surveys related work on com-

ponent models and integration of real-time aspects in middleware; and Section 5

presents concluding remarks.

2 Composing Real-time Behaviors into DRE Applications

In conventional component middleware, there are multiple software development

roles, such as component designers, assemblers, and packagers. QoS-enabled com-

ponent middleware supports yet another development role the Qosketeer 3

who is responsible for performing QoS provisioning. QoS provisioning involves

pre allocating CPU resources, reserving network bandwidth connections, and

TAO, CIAO, and the tests described in this paper are available as open-source from

deuce.doc.wustl.edu Download.html.

monitoring enforcing the proper use of system resources at runtime to meet or

exceed application and system QoS requirements 12 .

To improve component reusability and provision resources robustly through-

out a QoS-enabled component middleware platform, QoS provisioning speci -

cations should be decoupled from component implementations and speci ed in-

stead via component composition metadata, such as ... This decoupling enables

QoS provisioning speci cations to be checked and synthesized via model-based

tools 9, 13, which increase the level of abstraction and automation of the DRE

system development process. This separation of concerns also makes DRE sys-

tems more exible, easier to maintain, and easier to extend with new QoS capa-

bilities to handle changing operational contexts. As DRE systems grow in scope

and criticality, however, a key challenge is to decouple reusable, multi-purpose,

o -the-shelf, resource management aspects from aspects that need customization

for speci c needs of each system. This section describes how CIAO addresses this

challenge, presents an example DRE system that motivates our work on CIAO,

and then uses this example to compare the development process using conven-

tional DOC middleware technologies versus CIAO.

2.1 Supporting Real-time Aspects in CIAO

QoS provisioning requires component middleware that can meet the QoS re-

quirements of the DRE systems it supports. The interfaces and mechanisms for

QoS provisioning in the underlying operating systems and ORBs in conventional

component middleware platforms do not provide adequate support for develop-

ing and deploying DRE systems with stringent QoS requirements, as follows:

Since QoS provisioning must be done end-to-end, i.e., it needs to be ap-

plied to many interacting components, implementing QoS provisioning logic

internally in each component hampers reusability.

Since 1 some resources such as Real-time CORBA thread pools in CORBA

2.x 6 can only be provisioned within a broader execution unit i.e., a

component server rather than a component and 2 component designers

often have no a priori knowledge about other components, the component

itself is not the right place to provision QoS.

Since 1 some QoS assurance mechanisms such as checking whether rates

of interactions between components violate speci ed constraints a ect com-

ponent interconnections and 2 a reusable component implementation may

not know how it will be composed with other components, it is not generally

possible for components to perform QoS assurance in isolation.

Since 1 many QoS provisioning policies and mechanisms cannot work prop-

erly without installation of customized ORB modules such as and 2

there are inherent trade-o s between certain QoS requirements such as high

throughput and low latency , it is hard for QoS provisioning mechanisms im-

plemented within components to foresee incompatibilities without knowing

the end-to-end QoS requirements a priori.

To address the limitations of conventional component middleware in DRE

system domains, therefore, it is necessary to make QoS provisioning policies an

integral part of component middleware, while also decoupling QoS provision-

ing policies from component functionality. Over the past several years, we have

developed extensions to conventional component middleware that support com-

posing real-time aspects and mechanisms more e ectively by:

Separating the concerns of managing QoS resources from those of compo-

nent design and development so QoS management code is decoupled from

components and system modules that span multiple nodes in a distributed

system, and

Making component implementations more robust and reusable since QoS

provisioning via real-time aspects can now be composed with DRE systems

transparently to the component implementations.

These extensions have been integrated into the CIAO 10, which is our QoS-

enabled CCM implementation that separates the programming and provisioning

of QoS concerns as outlined above. Figure 1 depicts the key elements in the CIAO

architecture. Key building blocks in CIAO support the three major categories of

Client Client C nent e l

C nent e e

Cni ti n in Container Co onent o e

Co onent

e te et

e ti n

e eren e

t ti n

t et n le

e le t

e o o i ie

Co onent

li C nentC nne ti n

t ti n

e te o ro ert e i i ti n

a tor

e ni ea ie

t ti n o o i ie

l in

e li

e ni e ni

e ni

e te t ti n

l in l in

l in

Fig. 1. Key Elements in CIAO

CCM: 1 component implementation, 2 deployment and con guration, and 3

application runtime. CIAO applies a range of aspect-oriented 14 development

techniques to support the separation and composition of real-time behaviors and

other con guration concerns that must be consistent throughout many parts of

the software.

To support the composition of real-time behaviors, CIAO extends the build-

ing blocks in the component implementation" and application runtime" sup-

port categories of CCM to allow developers of DRE systems to specify the re-

quired real-time behaviors and to associate them with components in various

parts of an application. In particular, application components and the runtime

environment managed by CIAO can be con gured to support the speci ed be-

haviors. For example, CIAO's real-time component server runtime environment

and containers can be con gured to enforce di erent QoS aspects, such as pri-

orities or rates of invocation.

CIAO's real-time enhancements to CCM de ne a new le format known

as the real-time component assembly descriptor RTCAD to the set of XML

descriptors that can can be composed into an existing application assembly.

An RTCAD le contains de nitions of policy sets that specify key real-time be-

haviors and the resources required to enforce the behaviors. The resources and

policies de ned in CIAO's RTCAD les can be speci ed for individual compo-

nent instances. Qosketeers can then use CCM D&C tools to deploy the resulting

application assembly onto platforms that support the speci ed real-time require-

ments. The remainder of this section present an example that shows how CIAO's

real-time CCM enhancements can decouple QoS aspects from DRE system com-

ponents and enable them to be composed separately.

2.2 An Example DRE System

To illustrate CIAO's support for composing real-time aspects into DRE systems

concretely, we rst describe an example DRE system from the domain of avionics

mission computing 8 . Sections 2.3 and 2.4 then examine the steps required to

develop and evolve this example using CORBA 2.x versus CIAO's real-time

enhancements to the CORBA 3.x CCM speci cation. Figure 2 illustrates the

TIME

14:34:06

POSITION

N 43 39' W 93 21'

Rate Generator GPS Subsystem Graphical Display

Fig. 2. Example DRE Avionics System

following primary software entities in our example DRE avionics system:

1. A Rate Generator, which wraps a hardware timer that triggers the pushing

of events at speci c periodic rates to event consumers that register for those

events.

2. A GPS Subsystem, which wraps one or more hardware devices for naviga-

tion. Since there is a delay in getting the location reading from the hardware

directly, a cached location value is served via the exposed interface to pro-

vide immediate response. The cached location value is refreshed when the

GPS software receives a triggering event and causes the controlling software

to activate the GPS hardware for updated coordinates. A subsequent trig-

gering event is then pushed to registered consumers to notify the availability

of a refreshed location value.

3. A Graphical Display, which wraps the hardware for a heads-up display

device in the cockpit to provide visual information to the pilot. This device

displays a cached location value that is updated by querying an interface

when the controlling software receives a triggering event.

This example is representative of a class of DRE systems where clusters of

closely-interacting components are connected via specialized networking devices,

such as VME-bus backplanes. Although the functional characteristics of these

systems may di er, they often share the rate-activated computation and dis-

play output QoS constraints illustrated here.

2.3 Comparing DRE System Development using CORBA 2.x

versus CIAO

The rst step in developing a DRE system with either the CORBA 2.x DOC mid-

dleware speci cation supported by TAO or the CORBA 3.x CCM middleware

speci cation supported by CIAO involves de ning interfaces for the interac-

tions between software entities. For example, to implement our example DRE

avionics system using real-time DOC features of CORBA 2.x, a developer must

rst de ne the interface for interactions, such as sending the triggering message

and querying the GPS for the current location reading. After these interfaces

are de ned, implementing the avionics example using CORBA 2.x involves the

following steps:

1. Develop servant implementations for previously de ned interfaces. These

implementations are often speci c to system hardware.

2. Determine the location of each servant implementation in the network of

controllers. Hardware layout often dictates the selection of locations.

3. Based on decisions made in the previous steps, implement each server pro-

cess as follows: 1 initialize and con gure the ORB and hardware devices,

2 initialize and con gure POAs to suit the needs of di erent servant imple-

mentations, 3 instantiate servants, register them with POAs, and activate

them, 4 if needed, initialize and con gure an event delivery mechanism,

5 acquire necessary object references for the system, i.e., connect the ref-

erenced objects to this process, and 6 facilitate synchronization with other

services and server processes so they are initialized in the right order.

4. Deploy the assembled implementations to the target platforms manually or

via proprietary scripts.

Figure 3 presents a CORBA 2.x design for our example DRE avionics system.

As the list of steps above indicates, much of the overall system functionality in

CORBA 2.x is implemented in the server process and involves complex coordi-

nation among con guration and initialization code for speci c hardware, ORB,

POA, object connections, and initialization. This complexity is inherent to the

CORBA 2.x development paradigm and requires careful programming of all ob-

jects and server processes involved.

In contrast, the CIAO CCM-based development paradigm provides a more

scalable environment for managing key aspects of developing DRE systems. Fig-

ure 4 presents a CIAO CCM-based design for our example DRE avionics system,

where each hardware device is wrapped within a component implementation. Af-

ter the interfaces de ning the interactions between hardware devices are de ned,

CIAO's development lifecycle involves the following steps:

Fig. 3. CORBA 2.x Scenario for the DRE Avionics System

Fig. 4. CIAO Scenario for the DRE Avionics System

1. Identify a unit of installation as a component interface and design how the

component interacts with external components by de ning the component's

ports and attributes. It is straightforward to identify the software component

interfaces in this example since they map directly to hardware components.

2. For each type of component, developers create one or more component imple-

mentations e.g., for di erent hardware or internal algorithms and bundle

them as component packages.

3. An implementation of the DRE system can then be composed by de ning

a CCM assembly le where developers 1 select the component implemen-

tations to use from a pool of available component packages which need

not involve con guring any platform or runtime requirements, such as in

the ORB or POA , 2 describe how to instantiate component instances us-

ing these component implementations, and 3 specify connections between

component instances.

4. Deploy the DRE system onto its runtime platforms using the standard CCM

Deployment and Con guration D&C framework and tools 15 .

Compared with CORBA 2.x, CIAO's CCM-based development paradigm

handles much of the complexity for DRE system developers. Developers can

therefore focus on the domain problems at each development stage, without being

distracted by low-level implementation details of the con guration platform,

ORB, POA, and servant activation that are not related directly to application

logic. Moreover, CIAO provides many exible ways to con gure a DRE system.

For example, the actual rate for the rate generator component can be speci ed as

a default attribute value in a CCM component package and or be overwritten in

an application assembly by a Qosketeer. In contrast, CORBA 2.x systems require

direct modi cations to the application code, often by developer responsible for

implementing the application functionality.

2.4 Comparing DRE System Evolution Using CORBA 2.x versus

CIAO

When an existing DRE system is modi ed due to changes in DRE system re-

quirements or available hardware, the bene ts of CIAO's development paradigm

become even clearer. For example, consider how our avionics example could be

extended to include a collision warning subsystem to notify the pilot of immi-

nent danger, consisting of a Rate Generator, a Collision Radar, and a Warning

Display. Due to the critical nature of the collision warning subsystem, an addi-

tional requirement for this extension is that the collision warning subsystem be

allocated resources in preference to the navigation subsystem. For example, the

collision warning subsystem may run at a slow rate but it would likely always

run at a higher priority than that of the navigation subsystem since when a col-

lision alert was sounded, the pilot would perform an evasive maneuver to avoid

a collision, rather than worrying about the exact location of the aircraft.

To evolve the solutions described in Section 2.3 to meet these new require-

ments, developers of DRE systems must rst create the new software entities

for the collision warning system and then integrate their functional aspects into

existing applications. In addition, systemic QoS aspects, such as designation of

thread pools and assignment of thread pool priorities, must be performed to

ensure preferential operation of the collision warning subsystem.

Extending a CORBA 2.x implementation of our example DRE avionics sys-

tem would require developers to perform the following steps:

1. Create new servant implementations for the Collision Radar, Warning Dis-

play, and possibly Rate Generator.

2. Recon gure ORBs and POAs to accommodate and activate the new interface

implementations.

3. Modify code at di erent points in the two subsystems to assign priorities,

allocate thread pools, and set other ORB and POA policies so they interact

and synchronize appropriately during system execution.

With CORBA 2.x, moreover, adding the code for resource allocation and real-

time policy speci cations would require additional intrusive modi cations to

application code, beyond those needed to integrate the subsystems's functional

aspects.

Figure 5 illustrates how a CIAO-based implementation can be con gured

rather than programmed to support the new extensions outlined above. A key

observation is that in CIAO the added components have the same interfaces as

Fig. 5. Extended DRE Avionics System Scenario in CIAO

the original example DRE system, even though they require di erent implemen-

tations to interact with di erent hardware devices, including a collision radar

and the warning light speaker in the cockpit instrument cluster.

With CIAO's extensions to the CCM development paradigm, extending our

example DRE avionics system becomes relatively straightforward, requiring the

following steps:

1. Component developers write the new component implementations and pack-

age the new implementations with component metadata.

2. Application developers use the new component implementation packages to

compose the additional functionality into the new DRE avionics system via

the standard CCM D&C assembly format.

3. Qosketeers then de ne the QoS aspects i.e., resources and policies asso-

ciated with end-to-end real-time behavior, using CIAO's RTCAD format

described in Section 2.1.

This aspect-oriented approach for con guring real-time properties supported by

CIAO requires neither changes to the component implementations in our exam-

ple DRE system nor any customized server modi cations. Instead, this approach

allows the real-time behavior of our example DRE avionics system to be changed

simply by composing the new real-time behaviors into its application assembly

speci cation via CIAO's RTCAD format. Creating modi cations and variants

to DRE systems with di erent real-time behaviors therefore largely reduces to

deploying di erent application assemblies with CIAO. Moreover, many of these

separate development steps can be separated into di erent development roles, so

that developers such as Qosketeers can acquire and apply specialized expertise

in particular focus areas of the overall DRE system development process.

3 Performance Evaluation

Section 2 presented a qualitative comparison of the steps involved in develop-

ing and evolving DRE systems using CORBA 2.x vs. CORBA 3.x. This section

presents the design and results of experiments that quantitatively evaluate the

e ectiveness of CIAO's support for composing systemic QoS aspects to achieve

real-time behavior. These experiments illustrate how di erent real-time behav-

iors can be composed and con gured into existing applications via CIAO's real-

time extensions described in Section 2.1. To achieve this goal, all experiments

used components whose functional implementation was amenable to but de-

coupled from any real-time aspects.

The components used in the experiments presented in this section consisted

of 1 a client component that initiated processing and 2 a worker component

that performed a speci ed workload, akin to the relationship between the Rate

Generator and GPS components in Figure 4. Di erent real-time aspects were

then composed with these components in the experiments to model the following

two types of tests:

TAO real-time tests, which were presented in earlier work on the real-time

features of CORBA 2.x in TAO 16 . In these tests, procedures for di erent

tests were hard-coded into many client and server execution paths which, in

turn, depend on complicated logic and scripts to determine the exact tests

to perform.

CIAO real-time tests, where di erent tests were composed rather than

programmed by selecting and connecting di erent combinations of compo-

nents and systemic policies. Fewer component implementations were there-

fore implemented to perform the tests using CIAO.

In addition to empirically evaluating CIAO and TAO, these two types of tests

highlight the bene ts of the CIAO development paradigm illustrated in Sec-

tions 2.3 and 2.4. In particular, the variations in QoS aspects were managed

directly via reuse of CIAO con guration mechanisms and speci cation formats,

rather than through additional manual programming with C++ in the TAO

CORBA 2.x approach.

3.1 Testbed Hardware and Software

Two single-CPU 2.8 Ghz Pentium-4 computers with 512 MB of memory and 512

KB of on-chip cache memory served as deployment targets, providing the execu-

tion environment for the experiments performed in this chapter. Both machines

ran KURT-Linux 17 2.4.18, which provides a highly predictable experimenta-

tion platform. Two other single-CPU 2.53 Ghz Pentium-4 computers with the

same OS and memory con guration as the 2.8 Ghz machines were used to de-

ploy the test programs. All four machines were connected via switched 100 Mbps

Ethernet.

All test programs, libraries, and tools were based on TAO version 1.3.5 and

CIAO version 0.3.5 and compiled using GCC version 3.2 with no embedded

debug information, and with the highest level of optimization O3 . All compo-

nent implementations used in the test are implemented using the CCM session

component category, which provides the functionality most relevant to the DRE

systems. To remove spurious variability from the tests, all application processes

ran as root in the KURT-Linux real-time scheduling class, using the sched fifo

policy.

The basic interactions in the TAO real-time tests occurred between a test

object component provided by the server and a client invoking an operation

on the object component, thus requesting the server to perform an increment of

CPU-intensive work. Di erent tests were derived from di erent con gurations of

the server and client. For example, the number of objects components handled

by the server and their real-time constraints were varied. Clients were also con-

gured with di erent numbers of threads, each invoking operations in the server

with di erent workloads in di erent ways, e.g., at a xed rate vs. continuously.

CIAO real-time tests needed only two basic component types, called Con-

troller and Worker, to emulate the TAO real-time tests. A Worker component

provides a common interface that contained an operation that a client invoked

with an in parameter named work to specify the amount of work to perform.

The CIAO real-time tests only required one Worker component that performed

the speci ed amount of CPU computation when requested.

A Controller component uses a common interface to request that a connected

Worker component perform a unit of work. Several Controller implementations

were provided for the experiments. Each Controller implemented a particular

invocation strategy, such as continuous or rate-based at 25, 50, or 75 Hz rates .

A Controller component also supports an interface for starting and stopping

the test operation and outputting the statistic results observed in the controller.

Multiple Controllers thus acted as the source of execution threads invoking oper-

ations at the server component at di erent rates. These experiments were based

on the component design architecture found in modern avionics mission com-

puting systems, as described in Section 2.2.

3.2 Experiment 1: CIAO vs. TAO Invocation Performance

Experiment goal. This experiment evaluated the performance overhead to com-

ponentize DRE systems with the real-time features in CORBA 2.x enabled in the

TAO ORB and using CIAO's real-time component server environment described

in Section 2.1. Although TAO and CIAO can be con gured without support for

Real-time CORBA features, those features are needed by many types of DRE

systems, such as the example avionics application shown in Figure 2. We there-

fore focused on the performance of TAO and CIAO with Real-time CORBA

features enabled.

Experiment design. The implementation of this test in TAO consisted of a pair

of servants running on two test machines. The CIAO implementation of this test

used two component implementations, where one provides the target interface,

while the other component uses the same interface to invoke the benchmarking

operation. The CIAO test was built by using standard OMG tools to deploy the

two components to the same two machines used for the TAO test.

Experiment 1 measured and compared performance by invoking a simple

operation repeatedly in each test using either TAO or CIAO. We measured

the latency of each call and the number of calls made per second. We then

computed statistics to quantify the variability and average performance of each

implementation, i.e., in terms of average throughput and latency, maximum

latency of all calls, maximum latency of the lower 99 of the calls, and the

standard deviation in the latency of all calls.

Compared to TAO, an operation invocation on a CIAO component incurred

an additional virtual method call when a generated servant forwards the invo-

cation to the executor. Likewise, when a component invokes an operation on a

receptacle interface, it must rst retrieve the object reference stored in the con-

tainer before invoking the operation on it. The cost for both the virtual method

call and the retrieval of an object reference should ideally be predictable and

small. This experiment therefore selected an operation signature with a small

message payload, which made the overhead of CIAO stand out in comparison

and o ers an approximation of the worst-case CIAO performance di erence for

non-trivial operation invocations. Not including the length of other protocol

headers, an 8 byte message payload was sent over the network, which reduced

the time spent marshaling the data and sending the message over the network.

Experiment results. Figure 6 shows the throughput results measured in this

test, which were 8,420 and 8,107 calls sec for TAO and CIAO, respectively.

These results show that CIAO incurs a 3.7 reduction in average throughput

compared to TAO when CORBA 2.x real-time features are enabled in both

ORBs. The latency and variability results from this experiment are shown in

Figure 7. This gure shows the average latencies of TAO and CIAO calls were

118.9 sec and 122.9 sec, respectively, indicating an increase of 4 sec 3.4

in average latency. This result is consistent with the real-time ORB and CIAO

real-time component server throughput results, and shows that the overhead

imposed by CIAO's implementation when using CORBA 2.x real-time features

is relatively small.

The other graphs in Figure 7 show the standard deviations, 99 latency

bounds, and maximum measured latencies for TAO and CIAO with CORBA

2.x real-time features enabled. The standard deviations were again both small,

i.e., less than 2 sec for both TAO and CIAO real-time tests. TAO's measured

real-time latency had 99 of all samples under 123 sec, and 99 of the mea-

surements for CIAO fell within 127 sec. In both cases, 99 of all samples fell

within 4 sec above their average latencies. The maximum latency results for

TAO and CIAO tests were also comparable, at 182 sec for TAO and 219 sec

for CIAO.

Analysis of results. The results depicted in Figure 7 show that with real-time

features enabled the average- and worst-case performance for CIAO was slightly

worse than for TAO, but was reasonably close overall. The results demonstrate

10000

9000

8000 TAO + RT-ORB

8420 CIAO + RT

7000 Component

Throughput (calls/sec)

Server

8107

6000

5000

4000

3000

2000

1000

Fig. 6. Throughput Comparison between TAO and CIAO

that CIAO incurs only a small amount of overhead for supporting various CCM

mechanisms and interfaces. As the payload size increases, moreover, CIAO's

relative performance overhead in terms of throughput and latency will diminish

accordingly. In addition, the results show that CIAO does not greatly a ect jitter

relative to TAO. In general, these results demonstrate the suitability of CIAO

in the DRE application domain.

3.3 Experiment 2: Multiple Fixed-rate Controller Worker Pairs

Experiment goal. This experiment evaluates the behavior of a server handling

multiple worker threads over a range of workload without any real-time schedul-

ing, priority assignment or admission control at the middleware level.

Experiment design. This experiment consisted of three Controller Worker pairs

running concurrently. Each controller made requests to the worker at its respec-

tive xed rate of 25, 50, and 75 Hz i.e., at 25, 50, and 75 times per second,

respectively . The worker handles requests from each individual Controller by

doing the speci ed amount of work in separate threads. When invoking an op-

eration on the Worker, a Controller will block until the invocation returns from

the Worker. If a Worker can not handle the request at the given rate, therefore,

a Controller will not be able to invoke operations at its designed rate.

This experiment measures the rate at which each of the three Controllers

can make requests to the Worker components under di erent workloads. The

total work performed by all three worker threads eventually exceeds the amount

Mean 99%

140 140

123 127

122.9

118.9

120 120

100 100

80 80

( s)

60 60

40 40

20 20

0 0

Standard Deviation Maximum

2.0 250

219

182

1.58

1.38 200

1.5

150

( s)

1.0

100

0.5

0.0 0

Fig. 7. Latency Comparison between TAO and CIAO

of work the server can handle since the server's capability to perform work is

limited by the speed of its CPU. Since all three worker threads perform the

same amount of work, we expect one or more worker threads will not be able

to maintain the designated rate when the workload increases to the point where

the server can no longer complete the 150 requested invocations per second.

Experiment results. Figure 8 shows the measured results from the experiment.

This gure shows that when the workload increases initially from 20, all three

Controllers can achieve their designed rates. After the workload increases to

above 110, however, the 75 Hz Controller starts falling short of its target rate.

Similarly, above a workload of 130 repetitions the 50 Hz Controller also falls short

of its target rate. Above 210 repetitions all three Controllers fail to perform at

their designed rates of invocation.

Analysis of results. As expected, there is only a bounded amount of computation

power and the rate at which Worker components can handle requests eventually

decreases as workload increases. Indiscriminately failing to meet the invocation

rate of controllers, however, is often not acceptable for DRE systems. Instead,

certain tasks must meet their execution rates even if there are not enough com-

putation resources to enable all tasks to run at the speci ed rates.

25hz 50hz 75hz

Throughputs (calls/sec)

Work Load

Fig. 8. Achievable Rates vs. Workload

3.4 Experiment 3: Prioritized Workers using Threadpools with

Lanes

Experiment goal. This experiment evaluates the e ectiveness of composing real-

time behaviors into an application using the CORBA 2.x threadpools with lanes

strategy to manage the reservation of processing resources. In a thread pool

model without lanes, all threads in a thread pool have the same assigned priority

and the priority is changed to match the priority of a client making the request.

In the thread pool model with lanes, conversely, threads in a pool are divided

into lanes that are assigned di erent priorities. The priority of the threads does

not change once assigned.

Experiment design. This experiment allocates a single thread pool with multiple

lanes for di erent priorities. Although the CIAO deployment tools still create

multiple containers for host component of di erent priorities, they all share the

same thread pool using this approach. We rst assigned priorities according to an

increase rate, increase priority" IRIP strategy, also known as the Rate Mono-

tonic 18 assignment of priorities. The same experiment is also performed with

the anti-RMS increase rate, decrease priority" IRDP strategy, to demonstrate

CIAO's ability to con gure a wide range of strategies for priority assignment and

other real-time aspects.

Experiment results. The result of using threadpool with lanes with the IRIP

strategy is shown in Figure 9. This approach yields the same result as that of

using RMS with individual threadpools. Similarly, the result of composing the

anti-RMS real-time behaviors with threadpool with lanes in Figure 10 shows

that alternative priority assignments, such as IRDP, can be enforced e ectively

for thread pools with lanes.

25 Hz (Low Prio) 50 Hz (Mid Prio) 75 Hz (High Prio)

Throughputs (calls/sec)

Work Amounts

Fig. 9. IRIP with Threadpool Lanes

Analysis of results. The results in Figure 9 and 10 show that the composed real-

time behaviors successfully added the desired real-time aspects, i.e., prioritizing

task handling. In the experiments, real-time aspects were composed at di erent

stages, i.e., real-time CORBA policies and resources at the component assembly

stage and certain real-time ORB con gurations at the deployment stage. More-

over, the applied RTCAD le utilized CIAO's support for composing real-time

aspects at di erent granularities in an application, i.e., threadpool con gurations

at the per-ORB level and sets of real-time policies at the container level.

The bene t of the CIAO development paradigm is evident when compar-

ing the equivalent experiment programs used in TAO see 16 and those used

in CIAO that are described here. TAO's real-time experiments require com-

plex logic in both the client and server test programs and the collaboration of

complicated script to cover con gurations for all real-time behaviors performed.

In comparison, the CIAO-based tests are composed by using component imple-

mentations and XML de nitions to specify the test applications and real-time

behaviors, which is much easier to manage and maintain. Since XML de nitions

for key component properties are directly readable rather than being entangled

with application code systems built using the CIAO development paradigm are

also easier to analyze.

3.5 Summary of Results

The experiments described in this section show that CIAO adds only a small

amount of overhead, by comparing the performance of a CIAO application to an

equivalent one based on TAO. Moreover, the proportion of overhead is expected

to diminish with any increase in the size of an operation payload.

The current implementation of CIAO does, however, demand more secondary

storage and primary memory for running CIAO applications, due to the addi-

25 Hz (High Prio) 50 Hz (Mid Prio) 75 Hz (Low Prio)

Throughputs (calls/sec)

Work Amounts

Fig. 10. IRDP with Threadpool Lanes

tional code required to provide a common CCM runtime environment consisting

of containers and component servers. For simple test applications, this over-

head may be relatively large, though for large-scale DRE systems the additional

storage requirement is expected to be less signi cant compared to the storage

requirements of the applications themselves. The extra footprint and storage

space required by CIAO is also expected to lessen as implementation of CIAO

matures and when the dependencies on unused libraries are removed as future

work.

This section also showed that CIAO's runtime support for real-time applica-

tions imposes only a small amount of overhead to the overall performance and

does not adversely a ect predictability. Moreover, we have shown how CIAO's

real-time extensions particularly its RTCAD les that de ne the aspects i.e.,

resources and policies associated with end-to-end real-time behavior enable

the composition of real-time behaviors into an application exibly and e ec-

tively. Since developers can now integrate real-time behaviors throughout an

entire application end-to-end, these extensions make developing, maintaining,

and validating large-scale DRE systems easier.

The experiments performed in this work were modeled after existing TAO

real-time tests that validate TAO's CORBA 2.x Real-time CORBA features 19 .

Comparing CIAO's implementations to their TAO-based counterparts, one strik-

ing di erence is how easy it is to develop and modify CIAO-based tests. Develop-

ing TAO test programs requires writing new tests i.e., several speci c programs

are required to provide di erent test

ciao.dvi

Contact this candidate