University of Southern California Dissertations and Theses

Prediction of energy consumption behavior in component-based distributed systems

(USC Thesis Other)

Prediction of energy consumption behavior in component-based distributed systems

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content PREDICTION OF ENERGY CONSUMPTION BEHA VIOR
IN COMPONENT-BASED DISTRIBUTED SYSTEMS
by
Chiyoung Seo

A Dissertation Presented to the
FACULTY OF THE GRADUATE SCHOOL
UNIVERSITY OF SOUTHERN CALIFORNIA
In Partial Fulfillment of the
Requirements for the Degree
DOCTOR OF PHILOSOPHY
(COMPUTER SCIENCE)
August 2008
Copyright 2008 Chiyoung Seo
ii
DEDICATION
To my loving family
iii
ACKNOWLEDGEMENTS
First of all, I would like to thank my advisor, Professor Nenad Medvidovic, for his
kind support and guidance during my Ph.D. course. Whenever I was encountered by
some difficult problems in my research, he always encouraged me and kindly helped
me solve those problems. He was also the only person who gave me a research
opportunity, when I had to find my Ph.D. advisor again at USC four years ago. I also
would like to thank Professors Barry Boehm, Alice Parker, Leana Golubchik, and
Alexander Egyed for serving as the committee members and giving me very useful
comments on my research.
I was very fortunate to work with many smart friends and colleagues during the last
four years. Sam Malek helped me a lot in formalizing and developing the energy
consumption estimation framework for distributed Java-based systems. I would like
to thank George Edwards for his significant contributions in developing the style-
induced energy cost estimation framework. I also wish to thank many other good
friends in the Software Architecture Group at USC: Vladimir Jakobac, Chris
Mattmann, David Woolard, Somo Banerjee, Daniel Popescu, Yuriy Brun, and Ivo
Krka.
I would like to dedicate this dissertation to my loving family. I owed many thanks to
my older sister, Hyojung Seo, and older brothers, Chihwan Seo and Chiho Seo, for
their support and love. Finally, I would like to express my deep respect to my parents,
iv
Seongkyu Seo and Jungja Chang. Without all the sacrifices you have made for me, I
could not have succeed in this long journey.
v
TABLE OF CONTENTS
Page
Dedication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
CHAPTER 1: Introduction 1
CHAPTER 2: Proposed Research 10
2.1. Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2. Proposed Solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Research Hypotheses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1. Architectural Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2. Component’s Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.3. System’s Overall Energy Consumption Estimation . . . . 13
CHAPTER 3: Related Work 15
3.1. Architectural Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Energy Consumption Modeling and Measurement . . . . . . . . . . 18
3.3. Energy Saving Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
CHAPTER 4: Energy Cost Framework for a Distributed System’s Architectural
Styles 26
4.1. Overview of the Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2. Energy Consumption Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.1. Client-Server Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.2. Peer-to-Peer Style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.3. C2 Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.4. Publish-Subscribe Style . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.5. Pipe-and-Filter Style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.6. Energy Cost Comparisons of Architectural Styles. . . . . . 64
vi
4.3. Mappings to the Platform Constructs . . . . . . . . . . . . . . . . . . . . . 70
4.3.1. Client-Server Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.3.2. C2 Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.3.3. Publish-Subscribe Style . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.4. Characterizing the System’s Properties . . . . . . . . . . . . . . . . . . . 74
CHAPTER 5: Energy Cost Framework for Distributed Java-Based Systems 76
5.1. Overview of the Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2. Energy Consumption Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.1. Computational Energy Cost . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.2. Communication Energy Cost . . . . . . . . . . . . . . . . . . . . . . 83
5.2.3. Infrastructure Energy Cost . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2.4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.3. Energy Consumption Estimation . . . . . . . . . . . . . . . . . . . . . . . . 91
5.3.1. System Construction-Time Estimation . . . . . . . . . . . . . . 93
5.3.2. Runtime Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.4. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.5. Practical Applications of the Estimation Framework. . . . . . . . . 101
5.5.1. Determining the Deployment Architecture . . . . . . . . . . . 101
5.5.2. Off-Loading Components. . . . . . . . . . . . . . . . . . . . . . . . . 102
5.5.3. Modifying Components . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.5.4. Modifying the Deployment Architecture . . . . . . . . . . . . . 105
CHAPTER 6: Evaluation 106
6.1. Framework for a Distributed System’s Architectural Styles . . . 106
6.1.1. Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.1.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.1.3. Evaluation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.2. Framework for Distributed Java-Based Systems . . . . . . . . . . . . 122
6.2.1. Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.2.2. Selecting Java Components . . . . . . . . . . . . . . . . . . . . . . . 123
6.2.3. Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.2.4. Monitoring Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.2.5. Evaluation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
CHAPTER 7: Conclusions 140
7.1. Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
7.2. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
vii
LIST OF TABLES
Page
Table 6-1: Java-based components used in our evaluation....................................125
viii
LIST OF FIGURES
Page
Figure 1-1: A distributed sensor application designed in client-server (left) and
publish-subscribe (right) styles. .............................................................................4
Figure 3-1: JVM’s life cycle. .................................................................................19
Figure 4-1: A distributed Client-Server architecture. ............................................30
Figure 4-2: A distributed Peer-to-Peer architecture...............................................38
Figure 4-3: A distributed C2 architecture. .............................................................44
Figure 4-4: A distributed Publish-Subscribe architecture......................................52
Figure 4-5: A distributed Pipe-and-Filter architecture...........................................60
Figure 5-1: Interactions among distributed components........................................79
Figure 5-2: push interface of the Stack component and bytecodes executed per
push invocation. .....................................................................................................82
Figure 5-3: Energy consumption estimation steps at system construction-time
and at runtime.........................................................................................................92
Figure 6-1: Experimental setup..............................................................................107
Figure 6-2: C2 architecture in Prism-MW .............................................................108
Figure 6-3: Framework’s accuracy for the distributed application
in Figure 1-1...........................................................................................................111
Figure 6-4: A distributed sensor application designed in peer-to-peer (left) and
c2 (right) styles.......................................................................................................112
Figure 6-5: Framework’s accuracy for the distributed application
in Figure 6-4...........................................................................................................113
ix
Figure 6-6: A distributed sensor application designed in publish-subscribe (left)
and hybrid (right) styles. ........................................................................................114
Figure 6-7: Framework’s accuracy for the distributed application
in Figure 6-6...........................................................................................................115
Figure 6-8: A distributed rescue application designed in the C2 (left) and
the client-server (right) styles.................................................................................116
Figure 6-9: Framework’s accuracy for the distributed application
in Figure 6-8...........................................................................................................118
Figure 6-10: A mobile employee application designed in client-server (left)
and publish-subscribe (right) styles. ......................................................................119
Figure 6-11: Framework’s accuracy for the distributed application in
Figure 6-10.............................................................................................................120
Figure 6-12: An XML data stream application designed in pipe-and-filter (left)
and C2 (right) styles...............................................................................................121
Figure 6-13: Framework’s accuracy for the distributed application in
Figure 6-12.............................................................................................................122
Figure 6-14: Error rates of the framework for the components shown
in Table 6-1. ...........................................................................................................128
Figure 6-15: Error rates with respect to the number of simultaneously running
components. ...........................................................................................................129
Figure 6-16: Multiple regression for the find interface of the Shortest Path
component..............................................................................................................130
Figure 6-17: Accuracy of the framework for type III interface of DB and
Jess components.....................................................................................................131
Figure 6-18: Transmission (top) and receipt (bottom) energy estimation on
an iPAQ. .................................................................................................................133
Figure 6-19:A distributed Java-based mobile application comprising
three hosts...............................................................................................................134
Figure 6-20: Error rates of the framework with respect to the interaction
x
frequency (top) and the average size of a message (bottom).................................136
Figure 6-21: Error rates of the framework with respect to the numbers of hosts
and components......................................................................................................137
Figure 6-22: A distributed Java-based sensor application. ....................................138
Figure 6-23: Error rates of the framework with respect to the interaction
frequency................................................................................................................139
xi
ABSTRACT
Component-based distributed systems are increasingly deployed onto heterogeneous
embedded platforms with limited battery resources. In this domain, it is crucial to
provide an effective approach that enables an engineer to build energy-efficient
component-based distributed systems throughout the entire development cycle
spanning system design-time, construction-time, and runtime. To address this
problem, this dissertation first presents a framework that (1) facilitates early
estimation of the energy consumption induced by an architectural style in a
component-based distributed system, and (2) consequently enables an engineer to use
energy consumption estimates along with other quality attributes in determining the
most appropriate style for a given distributed system during design-time.
As the second part of the solution, this dissertation provides a framework that allows
the system engineer to estimate the energy consumption of a component-based
distributed system implemented in Java at the level of its components, both during
system construction-time and during runtime. We also present several practical
applications of the framework, which can be effected either at system construction-
time or at runtime for reducing the distributed system’s energy consumption and
consequently increasing the lifetime of the system’s key services.
Our overall approach, composed of the above two estimation frameworks, has been
evaluated empirically on a large number of distributed application scenarios, and
xii
produced very accurate energy consumption estimates. The dissertation concludes
with several open research questions that will frame our future work.
1
CHAPTER 1: Introduction
Component-based distributed systems increasingly execute in embedded, mobile, and
pervasive environments, whose computing platforms are usually characterized by
limited resources. One of the key resources, especially in long-lived systems, is
battery power. Unlike the traditional desktop platforms, which have uninterrupted,
reliable power sources, a newly emerging class of computing platforms have finite
battery lives. For example, a space exploration system may comprise satellites,
probes, rovers, gateways, sensors, and so on. Many of these are “single use” devices
that are not rechargeable. In such settings, minimizing and balancing the system’s
power consumption, and thus increasing its lifetime, becomes as important as the
more traditional quality-of-service concerns, such as reliability, security, fault-
tolerance, availability, communication latency and so forth.
Most previous approaches to addressing energy constraint issues in embedded,
mobile, and pervasive environments can be classified into the following two
categories: (1) energy modeling and estimation for embedded applications and (2)
energy saving and optimization on resource-constrained devices. However, most
approaches to modeling and estimating the energy consumption of embedded
software have only focused on specific hardware and OS platforms. In addition, a
majority of existing energy saving techniques merely consider reducing the energy
consumption incurred by individual user applications in a single device. Therefore,
2
these approaches are not adequate for enabling an engineer to build energy-efficient
component-based distributed systems running on heterogeneous computing
platforms, throughout the entire system development cycle spanning system design-
time, construction-time, and runtime.
The principles of software architecture have been widely employed for addressing the
challenges of designing large-scale distributed, embedded, mobile, and pervasive
systems [35,67]. Software architectures provide abstractions for representing the
structure, behavior, and key properties of a software system [51,60]. They are
described in terms of software components (computational elements), connectors
(interaction elements), and their configurations (specific compositions of components
and connectors) [44]. Software architectural styles (e.g., publish-subscribe, peer-to-
peer, client-server) are key design idioms which further refine the vocabulary of
components and connectors and propose a set of constraints on how they may be
combined in a system.
Architectural decisions made early in the design process are a critical factor in the
successful development of a distributed system. In particular, the selection of an
appropriate architectural style has a significant impact on various system quality
attributes (e.g., latency, scalability, reliability, etc.) of the target system. Different
styles are recognized as inducing different quality attributes in software systems. For
example, publish-subscribe-based systems are scalable but may not be able to provide
3
performance guarantees; on the other hand, client-server-based systems may be
optimized for performance, but can suffer from scalability problems.
As discussed above, efficient energy usage is increasingly being defined as an
important quality attribute for embedded, mobile, and pervasive applications.
However, there are currently no available techniques for analyzing the impact of an
architectural style on a system’s energy consumption. In fact, unlike other quality
attributes, such as scalability and performance, a style’s energy consumption
characteristics are not understood even in such an informal and intuitive manner.
Consider as an illustration the distributed sensor application shown in Figure 1-1,
which is designed using two different architectural styles (client-server and publish-
subscribe) and is running on three battery-powered hosts. The FireAlarmReceiver
component deployed on Host 2 translates, aggregates, and fuses alarms received from
fire detection sensors periodically, and propagates them to the FireAlarmAnalyzer
component deployed on Host 1. Additionally, these alarms are logged by the
AlarmLogger component. The FireAlarmAnalyzer inspects and interprets the alarm
data to determine whether there is actually a fire. If the FireAlarmAnalyzer concludes
that there is a fire, it transmits a sensor-activation message to the FireAlarmReceiver,
which in turn sends an activation signal to all the fire sensors. An analogous
processing path takes place in the intrusion detection sensors,
IntrusionAlarmReceiver, and IntrusionAlarmAnalyzer components.
4
In the client-server architecture, which is based on a typical request-response
protocol, the Receiver components act as clients and invoke interfaces on the
Analyzer and Logger components via their local client-server connectors (such
connectors are commonly implemented as middleware stubs and skeletons, for
example). The client-server connector on Host 2 (or Host 3) then transmits a request
(received from its local Receiver component) to the Analyzer and Logger components
separately, which indicates that each alarm requires the transmission of two requests
from Host 2 (or Host 3). On the other hand, in the publish-subscribe architecture,
which uses a typical pub-sub interaction protocol, the Analyzer components subscribe
to either fire or intrusion alarm events, while the AlarmLogger subscribes to both
event types. When the FireAlarmReceiver publishes a fire alarm event, the pub-sub
connector (commonly implemented as a middleware pub-sub service) retrieves the
event’s subscribers (i.e., FireAlarmAnalyzer and AlarmLogger) and routes the event
Figure 1-1: A distributed sensor application designed in client-server (left) and
publish-subscribe (right) styles.
Fire
Alarm
Analyzer
Alarm
Logger
Fire
Alarm
Receiver
Host 1
Host 2
Intrusion
Alarm
Receiver
Host 3
Intrusion
Alarm
Analyzer
Client-Server
Connector
Client-Server
Connector
Client-Server
Connector
Client-Server
Connector
Client-Server
Connector
Fire
Alarm
Analyzer
Alarm
Logger
Fire
Alarm
Receiver
Host 1
Host 2
Intrusion
Alarm
Receiver
Host 3
Intrusion
Alarm
Analyzer
Pub-Sub
Connector
Pub-Sub
Connector
Publish-Subscribe
Connector
5
to them, which requires only one transmission from Host 2. Therefore, compared with
the client-server architecture, the publish-subscribe architecture requires fewer events
to be sent over the wireless network, but incurs the additional overhead of managing
lists of publishers and subscribers and performing lookup tasks.
Therefore, it is not clear which style is more energy efficient for the above distributed
application. On the one hand, if the system’s energy overhead due to exchanging
more data over the network in the client-server style is bigger than the energy
overhead from the publish-subscribe infrastructure, the publish-subscribe style would
consume less energy than the client-server style. On the other hand, if the energy
overhead due to managing publisher and subscriber lists and performing lookups is
greater than the energy savings from reduced network transmissions, the publish-
subscribe architecture will consume more energy. Consequently, it is impossible to
“eyeball” the solution in scenarios of even moderate size and complexity. To address
this problem, this dissertation presents a framework whose objective is to estimate the
impact of a distributed system’s architectural style on the system’s energy
consumption. The framework is intended to be used during architectural design-time,
which would enable an engineer to use energy consumption estimates, along with
other quality attributes, in determining the most appropriate style for an application
among its candidate styles.
6
We have applied this framework on five distributed systems styles [45,9]: client-
server, publish-subscribe, peer-to-peer, C2, and pipe-and-filter. We have evaluated the
framework for precision and accuracy using a particular middleware platform that
supports the implementation of these styles. In a large number of distributed
application scenarios, this framework exhibited excellent precision, in that it was
consistently able to correctly rank the five styles and estimate the relative differences
in their energy consumptions. Additionally, the framework has proven to be accurate
in the context of our chosen middleware platform: it consistently produced energy
consumption estimates that were within 7% of each style implementation’s actually
measured energy consumption.
Once a distributed system (e.g., see Figure 1-1) has been designed using the most
energy-efficient style(s), we can ask a number of additional questions about its energy
consumption during system construction-time and during runtime. For example, does
the location of a given component (e.g., FireAlarmReceiver) impact its energy
consumption rate? Would redeploying a component (e.g., FireAlarmAnalyzer) from
one host (e.g., Host 1) to another (e.g., Host 2) change the system’s, or a given system
service’s, life span? Can we compare the likely energy consumption profiles of two or
more candidate deployments of components onto their target hosts? What is the best
deployment for the system with respect to energy consumption?
7
The simple observation guiding this dissertation’s research is that if we could
estimate the energy cost of a given distributed system in terms of its constituent
components ahead of its actual deployment, or at least early on during its runtime, we
would be able to answer the above questions. In turn, this would allow us to take
appropriate, possibly automated, actions to prolong the system’s life span: unloading
unnecessary or expendable software components, redeploying highly energy-
intensive components to more capacious hosts, collocating frequently communicating
components, and so on.
To this end, this dissertation presents a framework that estimates the power
consumption of a component-based distributed system implemented in Java at the
level of its components, both prior to and during runtime. We have chosen to focus on
Java because it is increasingly used in constructing embedded, mobile, and pervasive
applications [18,24]. Clearly, certain types of software applications (e.g., highly
computationally intensive programs such as those recently considered by Mantovani
et al. [42]) will still call for solutions in languages such as C and C++ because of their
better performance and lower energy consumption. However, Java is becoming
attractive for embedded, mobile and pervasive applications because it supports
platform-independence, language-level dynamism, and relative ease of system
deployment and maintenance, all the while continuously improving in performance
and application footprint size.
8
One novel aspect of our estimation framework is its component-based development
perspective, which renders it well suited for distributed, embedded, mobile and
pervasive applications. To facilitate component-level energy cost estimates, we
suggest a computational energy cost model for a software component. We integrate
this model with the component’s communication cost model, which is based on the
experimental results from previous studies. This integrated model results in highly
accurate estimates of a component’s overall energy cost. Furthermore, unlike most
previous power estimation tools for embedded applications, we explicitly consider
and model the energy overhead of a host’s OS and an application’s runtime platform
(e.g., JVM) incurred in facilitating and managing the execution of software
components. This further enhances the accuracy of our framework in estimating a
distributed system’s energy consumption. Another contribution of this work is its
ability to adjust energy consumption estimates at runtime efficiently and
automatically, based on monitoring the changes in a small number of easily tracked
system parameters (e.g., size of data exchanged over the network, inputs to a
component’s interfaces, invocation frequency of each interface, etc.).
We have evaluated this estimation framework for accuracy on a large number of
distributed Java applications, by comparing its estimates against actual electrical
current measurements. Our results suggest that the framework is always able to
estimate the power consumed by a distributed Java system to within 5% of the actual
consumption.
9
The remainder of the dissertation is organized as follows. Chapter 2 describes the
problem definition that the dissertation addresses, and discusses the research
hypotheses underlying this dissertation. Chapter 3 presents an overview of the related
work. Chapter 4 describes the framework that estimates the impact of a distributed
system’s architectural style on the system’s energy consumption at design-time.
Chapter 5 explains the framework that can estimate the energy consumption of a
distributed Java system at the level of its components both during system
construction-time and during runtime. Chapter 6 presents the detailed evaluation
results of the two frameworks. Finally, Chapter 7 presents concluding remarks and an
overview of the future work.
10
CHAPTER 2: Proposed Research
In this chapter, we first present the formal description of the problem that is addressed
by our research. We then discuss our proposed solution for the problem and the
hypotheses underlying this research.
2.1 Problem Description
In our research, we address an energy-awareness problem during the design,
construction, and execution of component-based distributed systems. This problem
consists of the following two issues:
1. Estimating the Energy Consumption Induced by an Architectural Style. The
selection of an architectural style for a target component-based distributed system
during system design-time will have a significant impact on various quality
attributes (e.g., latency, reliability, scalability, and so on). In particular, efficient
energy usage is increasingly being defined as an important quality attribute in
embedded, mobile, and pervasive environments where hosts usually have limited
battery capacities. Therefore, it is essential to estimate the energy consumption
induced by an architectural style in a distributed system, and consequently enable
an engineer to use energy consumption estimates, along with other quality
attributes, in determining the most appropriate style for a target distributed system
during design-time.
11
2. Estimating the Overall Energy Consumption of a Component-Based Distrib-
uted System. In a component-based distributed system running on multiple heter-
ogeneous hosts, software components interact with each other for providing
various services to the system’s users. Since we target the environment where
hosts have limited battery capacities, it becomes very critical to estimate the over-
all energy consumption of a distributed system at the level of its software compo-
nents both during system construction-time and during runtime. The distributed
system’s overall energy consumption represents the aggregate energy consump-
tion on all the target hosts, caused by executing the system’s constituent compo-
nents.
2.2 Proposed Solution
To tackle the first issue of our energy-awareness problem, we propose the framework
that can model and estimate the energy consumption caused by a distributed system’s
architectural style [56]. The framework provides a uniform way of identifying the
characteristics of a style and modeling the energy cost based on its captured
characteristics. This framework can be therefore used for modeling and estimating the
energy cost of an arbitrary style. The energy cost models in our framework are
platform-independent. In Chapter 4 we demonstrate how these models can be refined
and applied to specific middleware platforms that support a chosen set of architectural
styles.
12
For the second energy-awareness issue, we present another framework, which
estimates the energy consumption of a component-based distributed system
implemented in Java during system construction-time, and refines the construction-
time energy estimates during runtime by monitoring the changes in a small number of
easily tracked system parameters [57,58]. This framework models a distributed
system’s energy consumption at the level of its components and, furthermore,
estimates the energy consumption of each component at the granularity of its public
interfaces. In addition, the energy consumption models in this framework are
platform-independent, allowing the framework to be used for distributed Java
systems running on heterogeneous platforms.
2.3 Research Hypotheses
In this section, we describe the research hypotheses on which this dissertation is
based.
2.3.1 Architectural Style
There usually exist multiple candidate architectural styles that can be used for
developing a target distributed system, and be compared with respect to key quality
attributes.
Hypothesis #1 (precision): A framework can be devised with the ability to compare
quantitatively the candidate styles for a target component-based distributed system
13
with respect to their induced energy costs, and correctly rank these candidate styles
according to those costs.
Hypothesis #2 (accuracy): The energy cost estimates from the framework are on the
average within 7% of the actually measured energy consumption induced by each
candidate style’ s implementation.
2.3.2 Component’s Interfaces
In a component-based distributed system, each component interacts with other
components via its constituent public interfaces. Hence, a component has its own
implementation behind each interface, and executes the corresponding
implementation whenever one of its interfaces is invoked by other components.
Hypothesis #3: The energy consumption behavior of each component can be
accurately characterized by, and is directly proportional, to the energy costs
associated with its constituent interfaces.
2.3.3 System’s Overall Energy Consumption Estimation
In some domains (e.g., distributed real-time embedded systems), a system’s expected
runtime properties (e.g., expected inputs to a component’s interface, invocation
frequency of a component’s interface, sizes of messages exchanged between
components, etc.) are known during system construction-time.
14
Hypothesis #4: An energy estimation framework for systems in these domains can be
devised such that energy estimates made at construction-time fall on the average
within 5% of the actual energy costs measured at runtime. Alternatively, those
estimates can be refined during runtime in order to be within 5% of the actual energy
costs for other application domains.
15
CHAPTER 3: Related Work
In this chapter, we first explain previous techniques that can analyze various quality
attributes of software systems at the level of software architectures. We then discuss
approaches that characterize the energy consumption of embedded and mobile
systems, and explain several existing energy-saving techniques that can be effected at
the level of hardware or user applications.
3.1 Architectural Analysis
Software architectures provide abstractions for representing the structure, behavior,
and key properties of a software system in terms of software components
(computational elements), connectors (interaction elements), and their configurations
(specific compositions of components and connectors) [44]. The system’s
composition patterns and their constraints comprise software architectural styles
(e.g., publish-subscribe, peer-to-peer, client-server). Software architectural styles
refine the vocabulary of components and connectors and propose a set of constraints
on how they may be combined in a system. As architectural decisions made early in
the design process are a critical factor in the successful development of a software
system, there has been a lot of research on analyzing various quality attributes of
software systems at the architectural level. Wang et al. [80] have evaluated the
performance and availability of two software architectural styles. They modeled three
real applications (Unix sort, scientific, and statistics programs) in pipe-filter and
16
batch-sequential styles, and compared the two styles with respect to the above two
quality attributes. Their evaluation results showed that it is feasible to select a better
architectural style based on variations in the execution environment to attain higher
availability or better performance. In addition, they demonstrated the effects of these
variations on the quality attributes quantitatively.
Kazman et al. [26,27] have presented the Architecture Trade-off Analysis Method
(ATAM), which is a structured method for evaluating architecture-level decisions in
designing large-scale software systems with respect to various conflicting quality
attributes such as modifiability, performance, security, availability, and so forth.
Grahn et al. [15] characterized the performance of various architectural styles by
using an event-driven simulation approach. Especially, they compared pipe-filter,
layered, and blackboard styles with respect to various performance metrics (e.g.,
throughput, system response time, queue time for events, etc.). However, none of the
above architectural analysis approaches considered a software system’s energy
consumption as one of its relevant quality attributes.
We have participated in the development of the eXtensible Toolchain for Evaluation
of Architectural Models (XTEAM), a modeling and analysis framework targeted at
distributed, embedded and pervasive software systems in resource-constrained
environments [6]. XTEAM leverages the model-driven engineering (MDE) paradigm
to provide a reusable infrastructure for facilitating domain-specific architectural
17
analyses and weighing trade-offs between multiple design goals, such as
performance, reliability, and resource consumption in terms of memory and energy.
However, one main limitation of XTEAM, especially in performing energy
consumption simulations, is that XTEAM does not support energy consumption
analysis of a given distributed software system with respect to its candidate
architectural styles, but produces only energy consumption estimates for the fixed
topology (i.e., specific configuration of components and connectors) of a given
distributed system instead. In this dissertation, we have built our style energy
consumption analysis framework on top of XTEAM.
Previous research has proposed several classifications of software architectural styles.
Shaw et al. [59] have classified architectural styles into six categories (i.e., data flow,
call-and-return, interacting process, data-centered repository, data-sharing, and
hierarchical styles) based on their constituent parts, control issues, data issues, and
control/data interaction. Fielding [9] presented a survey of common architectural
styles (e.g., client-server, layered, C2, publish-subscribe, etc.) that can be used for
distributed systems. He evaluates each style according to various quality attributes in
building network-based hypermedia systems, but does not consider energy
consumption induced by an architectural style. Mehta [45] presented a systematic
understanding of architectural styles based on a small set of recurring architectural
primitives, and proposed an extensible composition framework for architectural
styles based on these primitives, which is, in turn, used as the basis for style
18
implementation. He also presented a survey of common architectural styles for
distributed systems, and characterized those styles based on the five dimensions (i.e.,
data, structure, interaction, behavior, and topology). These surveys actually form a
basis for choosing the target architectural styles used in our style energy consumption
analysis framework and characterizing them for modeling their induced energy costs
in a uniform way (detailed in Chapter 4).
3.2 Energy Consumption Modeling and Measurement
Previous research has suggested energy consumption models at the level of CPU
instructions [36,62,73,74]. These approaches are based on the following equation for
estimating the energy consumption of executing a sequence of n CPU instructions:
Eq. 3-1
where Base_Cost represents the energy cost required by the CPU for executing a
single instruction Inst
i
, and Inter_Cost is the energy cost of switching between
instructions Inst
i
and Inst
i+1
.
1

Although these approaches produce accurate energy consumption estimates for
embedded software, a system engineer would face at least two problems in using
them to estimate the energy consumption of software components: (1) Equation 3-1
1. The main contributor of the inter-instruction cost is circuit state overhead. Further elabo-
ration of this issue is outside the scope of this dissertation.
1
_ ( ) _ ( , )
1
1 1
n n
Base Cost Inst Inter Cost Inst Inst
i i i
i i
−
+ ∑ ∑
+
= =
19
only models the energy consumption of the CPU and does not take into account other
system elements such as main memory; and (2) since none of these approaches have
modeled the communication energy cost incurred by the remote interactions among
software components, the engineer cannot use them to accurately estimate the energy
consumption of a software system distributed across multiple hosts.
Several studies have profiled the energy consumption of Java Virtual Machine (JVM)
implementations. Farkas et al. [7] have measured the energy consumption of the Itsy
Pocket Computer and the JVM running on it. As shown in Figure 3-1, a JVM
generally has five stages during its life cycle [34]. Farkas et al. have discussed
different JVMs’ design trade-offs in each stage, studied their applicability to pocket
computers, and measured their energy consumption. The energy consumed at the
interpreter loop stage corresponds to the actual energy required to execute a Java
application. The energy consumed by the other stages is constant regardless of the
Java classes executed [33,34]. Lafond et al. [33,34] have measured the energy
consumption of each stage, and showed that the energy required for memory accesses
usually accounts for 70% of the total energy consumed at all the stages. They also
measured the energy consumption of each bytecode interpreted by Sun Microsystems’
KVM [31] at the interpreter loop stage. Vijay et al. [77] have discussed the
characteristics of the energy consumption by cache and main memory when executing
the SPEC JVM98 benchmarks [68] in the just-in-time (JIT) and interpreter modes on
the Sun Labs Virtual Machine for Research, EVM [69]. However, none of these
20
studies suggest a model that an engineer can use for estimating the energy
consumption of a distributed Java system either prior to or during runtime.
There have been several tools that estimate the energy consumption of embedded
operating systems (OSs) or applications. Li et al. [37] have characterized the energy
consumption of the commercial OS, SGI IRIX 5.3 [61], by running various
applications on it, and provided energy consumption models for estimating its
runtime energy dissipation. Similarly, Tan et al. [71] have investigated the energy
behaviors of two widely used embedded OSs, μC/OS [32] and Linux [2], and
suggested their quantitative macro-models, which can be used as OS energy
estimators. Gurumurthi et al. [17] have proposed a power estimation tool, called
SoftWatt, using a computer system simulator, the SimOS [53], for estimating the
energy consumption of both an application and SGI IRIX 5.3 operating system. Sinha
et al. [64] have suggested a Web-based tool, JouleTrack, for estimating the energy
cost of an embedded software running on StrongARM SA-1100 and Hitachi SH-4
microprocessors. Flinn et al. [12] have developed a tool, PowerScope, which
estimates the power consumption of mobile applications running on the NetBSD
operating system [49] by combining the hardware instrumentation to measure current
Figure 3-1: JVM’s life cycle.
Start JVM
Initializing
JVM
Loading
the main class
Interpreter
loop
Exit Start JVM
Initializing
JVM
Loading
the main class
Interpreter
loop
Exit
21
levels with the kernel software support to perform the statistical sampling of system
activities. While they certainly informed our work, we were unable to use these
energy estimation tools directly in our targeted distributed Java domain because none
of them provide generally applicable energy consumption models, but instead focus
on individual applications running on specific OSs and platforms.
Previous research has also proposed solutions for the energy accounting problem that
attributes the overall energy consumption of a system to individual user-level
processes in an operating system[50,83]. Although these approaches have some
similarities with our energy estimation framework, we cannot directly use them for
estimating a distributed system’s energy consumption at the level of its components
because a process does not always correspond to a single software component (e.g., in
Java, there are usually multiple software components running in a single JVM
process).
Recently, researchers have attempted to characterize the energy consumption of the
Transmission Control Protocol (TCP) [63,79]. Singh et al. [63] measured the energy
consumption of four variants of TCP (i.e., Reno, Newreno, SACK, and ECN-ELFN)
in ad-hoc networks, and showed that ECN-EFLN has a lower energy cost than the
others. These studies also show that since TCP employs a complicated mechanism for
congestion control and error recovery, modeling its exact energy consumption
remains an open problem. While we plan to incorporate into our framework the future
22
advancements in this area, as detailed in Chapter 5 this dissertation relies on the User
Datagram Protocol (UDP). UDP does not provide any supports for congestion
control, retransmission, error recovery, and so forth, making it easier to estimate its
energy cost.
In fact, several studies [8,14,82,83] have measured the energy consumption of
wireless network interfaces on handheld devices by using UDP as a transport layer
protocol. They have showed that the energy usage by a device due to transmitting or
receiving data over the network is directly linear to the size of data to be transmitted
or received. We use these experimental results as a basis for defining a component’s
communication energy cost.
3.3 Energy Saving Techniques
There have been extensive research efforts that study the problem of energy-efficient
task allocation and scheduling in uni-processor embedded systems. Flautner et al.
[10] implemented a power management kernel module for Linux, Vertigo, which
monitors program execution and controls the speed and voltage levels of a processor
for reducing its power consumption. Vertigo provides multiple performance-setting
algorithms for a processor, and allows the composition of these algorithms, all
specializing in different kinds of runtime situations. The most applicable composition
for a given condition is chosen at runtime. Similarly, Lorch et al. [38] have suggested
a task-based speed and voltage scheduler for a processor on the Windows 2000
23
operating system. They provided PACE, an algorithm that determines the most
energy-efficient schedule for satisfying each task’s performance requirements. The
basic behavior of this algorithm is to assign a low CPU speed to each task at its
beginning stage, and increase the speed only if a task must be completed on time.
Several researchers have extended this task allocation and scheduling problem to
multi-processor systems. Zhang et al. [84] have devised a two-phase framework that
determines the allocation of tasks onto processors, and then the appropriate voltage
levels of processors for tasks by using integer programming. Similarly, Zhu et al. [85]
proposed a dynamic adjustment mechanism of a processor’s voltage levels for a
homogeneous multi-processor environment.
Helmbold et al. [19] suggested a machine learning-based algorithm that decides the
appropriate frequency of spinning down a mobile computer’s disk device for reducing
its energy consumption. Traces of disk activity are used as the inputs to the suggested
algorithm. Their algorithm can be also applied to other peripheral devices such as
wireless interface and display. Weissel et al. [81] proposed an approach that reduces
the energy consumption of I/O devices by using a new operating system interface for
cooperative I/O, which can be leveraged by user-level applications. With this
approach, applications can declare open, read, and write operations as deferrable and
even abortable by specifying a time-out and a cancel flag. An operating system can
use this information to delay and batch I/O operations so that the number of power
mode switches in I/O devices is reduced and the devices can be kept longer in a low-
24
power mode. Since these approaches are supported and managed by a host’s OS, they
can be integrated with various application-level energy-saving approaches on which
this dissertation focuses, for further saving and optimizing the energy resources in
distributed software systems.
Several researchers have presented application-level energy saving approaches on
mobile devices. Remote execution techniques have been suggested to reduce the
power consumption incurred by mobile applications. Remote execution techniques
split the functionality of an application into several components and enable some of
the components to be executed on resource-abundant servers connected with wall
power. Flinn et al. [11] proposed a remote execution system, Spectra, for battery-
powered devices used in a pervasive computing environment. Their system monitors
both application resource usage and the availability of resources in the environment,
and dynamically decides how and where to execute application components.
Similarly, Rudenco et. al [54] suggested the Remote Processing Framework, which
makes a decision about when to migrate a task from a portable computer to a
designated server over a wireless network and provides automated system-level
support for this task migration. However, these remote execution approaches assume
the existence of remote servers with abundant resources, which is not always true in
the areas of distributed, embedded, mobile, and pervasive systems.
25
Flinn et al. [13] have proposed a way of adjusting the quality levels of output
produced by mobile applications for achieving the user-specified battery duration.
Their approach monitors the remaining battery capacity on a mobile device and the
energy usage of each application, and then balances the conservation of an energy
resource and an application’s output quality level (e.g., by filtering and cropping
levels for a map viewer) dynamically at runtime. Narayanan et al. [48] have suggested
a history-based prediction approach that enables the system to monitor, analyze, and
predict the resource (e.g., energy, CPU, memory, etc.) usage of an application for
determining its appropriate quality level. Most of these application-level approaches
provide frameworks for estimating the energy consumption of individual
applications. However, their frameworks are restricted to multimedia applications
(e.g., video player, map viewer, speech recognition, and so forth). In addition, they
have focused only on individual mobile applications on a single host rather than a
distributed software system running on multiple heterogeneous hosts.
26
CHAPTER 4: Energy Cost Framework for a Distributed
System’s Architectural Styles
Fielding [9] and Mehta [45] identified more than twenty common architectural styles
for distributed systems. Among these styles, this dissertation has focused on the
client-server, publish-subscribe, C2, peer-to-peer, and pipe-and-filter styles because
each of them embodies a diverse set of recurring distributed systems concepts, such as
distribution, concurrency, event-based interaction, implicit invocation, layering,
remote procedure calls, and so forth. In this chapter we first show a uniform way of
capturing the characteristics of the above five styles, and modeling the energy
consumption induced by each style based on its captured characteristics. This
modeling approach is not limited to the above styles, but can be applied in modeling
the energy cost induced by an arbitrary style. We then discuss how the energy
consumption model of a given style can be mapped to a specific middleware platform,
and which properties of a target distributed system should be captured for estimating
the energy cost induced by its architectural style.
4.1 Overview of the Framework
Two assumptions underlying our framework are that (1) components interact with
other components via connectors and (2) connectors can communicate with other
connectors in addition to components. These assumptions are common in
architectural literature [51,60], and they do not limit the types of distributed systems
27
to which our framework can be applied. Based on these assumptions, the energy cost
of a component Comp
i
can be expressed as follows:
Eq. 4-1
In this equation, E
logic,i
is the computational energy cost of the component Comp
i
due
to executing its application logic, while E
commWithConn,i
represents the energy cost of
exchanging data with connectors attached to the component.
The energy consumption of a connector Conn
j
can be expressed as the following
equation:
Eq. 4-2
E
comm,j
represents the energy consumption of communication, which in a distributed
style amounts to the cost of exchanging data locally or remotely. Communication is
the major service of the four types of services that a connector may provide [46].
E
logic,j
represents the energy cost of the other three types of service:
• Coordination – A connector may support transfer of execution control among com-
ponents. Method invocations within a single process and inter-process communica-
tion (IPC) are examples of the coordination service.
• Conversion – A connector converts the interaction required by one component to
that provided by another. Marshalling and unmarshalling data for exchange over
the network is an example of the conversion service.
, ,
( )
i logic i commWithConn i
EC Comp E E = +
,
( )
j comm j logic,j
EC Conn E E = +
28
• Facilitation – A connector mediates and streamlines component interaction. Con-
nection establishment and a routing facility for delivering a message to its destina-
tion are examples of the facilitation service.
Based on this classification, we can calculate E
comm,j
and E
logic,j
as follows:
Eq. 4-3
Eq. 4-4
E
commWithComp,j
represents the energy consumption of exchanging data with the
components attached to the connector, while E
remoteComm,j
and E
localComm,j
are the
energy costs of the connector caused by exchanging data with remote and local
connectors, respectively. We should note that if a component and its attached
connector run as separate processes, their interactions would be supported by an IPC
mechanism, which incurs the energy overhead in both the component and its attached
connector [71].
Once the energy costs of the components and connectors induced by a candidate style
of a target distributed system have been calculated, the overall energy consumption
resulting from the style can be estimated as follows:
Eq. 4-5
, , , ,

comm j commWithComp j remoteComm j localComm j
E E E E = + +
, , , , logic j coordin j conver j facili j
E E E E = + +
1 1
( ) ( )
n m
i j
i j
overallEC EC Comp EC Conn
= =
 
 
 
 
= +
   
 
 
∑ ∑
29
where n and m are, respectively, the numbers of the system’s constituent components
and connectors. In the following section, we discuss how we can model the above
energy cost parameters for each of the five selected styles.
In our work, we assume that a component’s core business logic (e.g., logic for
processing messages received from other components) remains the same across all
the candidate styles for a target distributed system. We acknowledge that this logic
may need to be refactored in some cases. For example, the logic required by the
component for managing its interfaces will change, and may incur additional energy
overhead. We distinguish this energy cost from the cost associated with the
component’s core business logic, and account for it in E
commWithConn,i
of Equation 4-
1. Consequently, this indicates that the computational energy cost of a component
(i.e., E
logic,i
in Equation 4-1) remains the same across all candidate styles, which
means that our framework does not require the actual value of E
logic,i
while
performing the energy consumption comparisons of multiple styles. Therefore, we
only need to capture the following characteristics of a given style for modeling its
induced energy cost:
• A component’s behaviors in communicating with its attached connector.
• A connector’s behaviors in providing its four services (i.e., communication, coordi-
nation, conversion, and facilitation).
30
4.2 Energy Consumption Models
In this section, we first present a uniform way of characterizing each of our selected
five styles, and modeling the energy cost based on their captured characteristics. We
then discuss the energy consumption comparisons between different pairs of styles.
4.2.1 Client-Server Style
Figure 4-1 shows an example of a distributed software system designed according to
the client-server style. Connectors in this scenario are implemented as middleware
stubs and skeletons. A client or server component in this style has the following
behaviors in communicating with its attached connector:
1. A client component sends requests to and receives responses from its attached
connector.
2. A server component receives requests from and sends responses to its attached
Figure 4-1: A distributed Client-Server architecture.
Host 2 Host 1
Point-to-Point
Connector
Point-to-Point
Connector
Skeleton
Client
Stub
Server
31
connector.
Recall from Section 4.1 that we do not need to characterize the computational
behaviors of a client or server component as the computational energy cost of a
component (i.e., E
logic,i
in Equation 4-1) remains roughly the same across all
candidate styles.
On the other hand, a client’s or a server’s connector has the following behaviors in
providing its communication, coordination, conversion, and facilitation services:
Communication
1. A client’s connector receives requests from the client and forwards them to a
server’ connector, and then receives responses from a server’s connector and for-
wards them to the client.
2. A server’s connector receives and buffers requests from a client’s connector and
forwards them to the server, and receives responses from the server and sends
them to a client’s connector.
Coordination
1. A client’s connector transfers execution control to a client by passing a response
to the client.
2. A server’s connector transfer execution control to a server by passing a request to
the server.
32
Conversion
1. A client’s connector marshalls requests before sending them to a remote server’s
connector, and unmarshalls responses after receiving them from a remote server’s
connector.
2. A server’s connector unmarshalls requests after receiving them from a remote cli-
ent’s connector, and marshalls responses before sending them to a remote client’s
connector.
Facilitation
1. A client’s connector creates a connection object for sending requests to and
receiving responses from each server’s connector.
2. A server’s connector creates a connection instance in order to receive requests
from and send responses to each client’s connector.
Based on the above characterization, we can model the energy cost parameters
introduced in Equations 4-1 to 4-4. First, according to the communication behavior of
a client, the energy cost E
commWithConn,i
of a client Comp
i
due to sending requests to
and receiving responses from its attached connector can be calculated as follows:
Eq. 4-6
( )
, , ,
1
a
i
commWithConn i toConn k fromConn k
k
E E E
=
= +
∑
33
In the equation above, a
i
is the total number of requests made by the client. E
toConn,k
and E
fromConn,k
represent the energy costs due to sending the kth request to and
receiving the kth response from the connector, respectively. Based on the
communication behavior of a server component, E
commWithConn,i
of a server Comp
i
can be also calculated in the same manner using the above equation. The values of
E
toConn
and E
fromConn
depend on the communication mechanism used between a
component and its attached connector. For example, if a queue is used for
communication, the values of E
toConn
and E
fromConn
are constant, while they are
directly proportional to the size of data exchanged if IPC is used instead [71].
In accordance with the behaviors of a client’s connector in communicating with its
attached client, the energy cost E
commWithComp,j
of the connector Conn
j
caused by
receiving requests from and forwarding responses to the client can be calculated as
follows:
Eq. 4-7
b
j
is the total number of requests received from the client, while E
fromComp,l
and
E
toComp,l
represent the energy costs due to receiving the lth request from and sending
the lth response to the client. Based on the communication behaviors of a server’s
connector with its attached server, we can also calculate E
commWithComp,j
of a server’s
connector Conn
j
by using the above equation. The values of E
fromComp
and E
toComp
( )
, , ,
1
b
j
commWithComp j fromComp l toComp l
l
E E E
=
= +
∑
34
depend on the communication mechanism used between a connector and its attached
component.
To model the energy consumption due to remote exchange of data between the
client’s and server’s connectors, we assume that the total energy used is proportional
to the size of the data exchanged. This has been shown to be an accurate
characterization of commonly used network protocols, including TCP and UDP
[8,63,82]. Based on this energy behavior of remote communication and the behaviors
of a client’s connector in communicating with a server’s connector, E
remoteComm,j
of a
client’s connector Conn
j
due to sending c
j
requests to and receiving their responses
from remote servers’ connectors can be estimated as follows:
Eq. 4-8
tSize
l
and rSize
l
are the sizes (e.g., KB) of the lth transmitted request and its received
response. tEC and rEC are the energy costs (Joule/byte) on the connector’s host while
it transmits and receives a unit of data, respectively. tS and rS represent constant
energy overheads associated with channel acquisition [8]. Similarly, based on the
above remote communication’s energy behavior and the communication behaviors of
a server’s connector with a client’s connector, we can calculate E
remoteComm,j
of a
server’s connector Conn
j
as follows:
( ) ( ) ( )
,
1
c
j
remoteComm j l l
l
E tSize tEC tS rSize rEC rS
=
= × + + × +
∑
35
Eq. 4-9
d
j
is the total number of requests received over the network, and rSize
l
and tSize
l
are
the sizes of the lth received request and its transmitted response, respectively. E
buffer,l
is the energy cost of buffering the lth received request.
Local communication between the client’s and server’s connectors has an energy cost
that is different from the remote case. Based on the behaviors of a client’s connector
in communicating with a server’s connector, the energy cost E
localComm,j
of a client’s
connector Conn
j
caused by sending e
j
requests to and receiving their responses from
local servers’ connectors can be calculated as follows:
Eq. 4-10
where E
localTrans,l
and E
localReceiv,l
represent the energy costs of sending the lth
request and receiving its response, respectively. According to the communication
behaviors of a server’s connector with a client’s connector, we can also calculate
E
localComm,j
of a server’s connector Conn
j
due to receiving f
j
local requests and
sending their responses as follows:
( ) ( )
( )
, ,
1
d
j
remoteComm j l l buffer l
l
E tSize tEC tS rSize rEC rS E
=
= × + + × + +
∑
( )
, , ,
1
e
j
localComm j localTrans l localReceiv l
l
E E E
=
= +
∑
36
Eq. 4-11
E
localReceiv,l
and E
localTrans,l
represent the energy costs of receiving the lth request and
sending its response, respectively, while E
buffer,l
is the energy cost of buffering the lth
request received locally. The values of E
localTrans
, E
localReceiv
, and E
buffer
depend on
the communication mechanism (e.g., IPC, socket, shared memory, queue, etc.) used
for implementing the connector.
In the client-server style, the energy cost E
coordin,j
of a client’s connector Conn
j
due to
performing its coordination service does not need to be modeled separately because
the client’s connector transfers execution control to the client by passing a response to
it, whose energy cost is already captured by E
commWithComp,j
of the client’s connector.
Similarly, the energy cost E
coordin,j
of a server’s connector Conn
j
is not modeled
explicitly because that cost is already captured by E
commWithComp,j
of the server’s
connector.
Based on the characteristics of a client’s connector in performing its conversion
service, we can quantify the conversion cost E
conver,j
of the connector as follows:
Eq. 4-12
( )
, , , ,
1
f
j
localComm j localTrans l localReceiv l buffer l
l
E E E E
=
= + +
∑
( )
, , ,
1
c
j
conver j mar l unmar l
l
E E E
=
= +
∑
37
c
j
is the total number of requests sent remotely, while E
mar,l
and E
unmar,l
are the
energy costs of marshalling the lth request and unmarshalling its response,
respectively. According to the conversion behavior of a server’s connector, its
conversion cost E
conver,j
can be also calculated in an analogous manner using the
above equation.
Based on the facilitation service provided by a client’s connector, the facilitation cost
E
facili,j
of a client’s connector Conn
j
can be calculated as follows:
Eq. 4-13
E
remoteConn
and E
localConn
are the constant energy costs due to establishing a single
remote or local connection with a server’s connector, respectively. Num
remoteConns,j
and Num
localConns,j
are the numbers of remote and local connections established,
respectively. In the same manner, E
facili,j
of a server’s connector Conn
j
can be
calculated using the above equation according to its facilitation service.
Note that after a server processes a request, it does not always send a response for that
request to its client. In this case, the energy costs due to exchanging a response
between components and connectors in Equations 4-6 to 4-12 will not be incurred.
Also note that the energy cost parameters (e.g., E
toConn
, E
fromConn
, E
toComp
,
E
fromComp
, tEC, rEC, etc.) introduced in this section are platform-specific, i.e., their
values depend on the hardware, OS, and middleware on which a distributed
( ) ( )
, , , facili j remoteConn remoteConns j localConn localConns j
E E Num E Num = × + ×
38
application is deployed. All of these parameters can be readily obtained on a target
platform. We elaborate on how these parameters are determined for an actual platform
in Section 4.3. and Chapter 6.
4.2.2 Peer-to-Peer Style
In the peer-to-peer style, a component can provide services as well as invoke services
provided by other components. Figure 4-2 shows a distributed architecture designed
with the peer-to-peer style. In this architecture, a component Comp2 provides services
for a component Comp1, and also invokes services provided by a component Comp3.
A component in the peer-to-peer style has the following characteristics in
communicating with its attached connector:
1. A component sends requests to and receives responses from its attached connec-
tor.
2. A component also receives requests from and sends responses to its attached con-
Figure 4-2: A distributed Peer-to-Peer architecture.
Host 1
Host 2
Comp 1
Point-to-Point
connector
Comp 2
Point-to-Point
connector
Comp 3
Point-to-Point
connector
39
nector.
A connector has the following characteristics in performing its communication,
coordination, conversion, and facilitation services:
Communication
1. A connector receives requests from its attached component and forwards them to
the connectors attached to destination components, and then receives responses
from those connectors and forward them to its attached component.
2. A connector also receives and buffers requests from the connectors attached to
other components and forwards them to its attached component, and then receives
responses from its attached component and send them to the connectors of desti-
nation components.
Coordination
1. A connector transfers execution control to its attached component by passing a
response or request to that component.
Conversion
1. A connector performs marshalling requests or responses before sending them to
remote connectors, and also unmarshalling requests or responses after receiving
them from remote connectors.
Facilitation
1. A connector creates a connection object for sending requests to and receiving
40
responses from another local or remote connector.
2. A connector creates a connection object for receiving requests from and sending
responses to another local or remote connector.
According to the above characterization, we can first calculate the energy cost
E
commWithConn,i
of a component Comp
i
due to sending/receiving requests and
responses to/from its attached connector as follows:
Eq. 4-14
a
i
is the total number of requests sent by the component, whereas b
i
is the total
number of requests received by the component. E
toConn,k
and E
fromConn,k
represent the
energy costs due to sending the kth request to and receiving its response from the
attached connector, respectively. E
fromConn,l
and E
toConn,l
are the energy consumption
due to receiving the lth request from and sending its response to the attached
connector, respectively.
The energy cost E
commWithComp,j
of a connector Conn
j
caused by forwarding/
receiving requests and responses to/from its attached component can be calculated as
follows:
( ) ( )
, , , , ,
1 1
a b
i i
commWithConn i toConn k fromConn k fromConn l toConn l
k l
E E E E E
= =
= + + +
∑ ∑
41
Eq. 4-15
c
j
is the total number of requests received from the attached component, and d
j
is the
total number of requests received from the connectors of other components.
E
fromComp,m
and E
toComp,m
represent the energy costs of receiving the mth request
from and forwarding its response to the attached component, respectively. E
toComp,n
and E
fromComp,n
are the energy costs of sending the nth request to and receiving its
response from the attached component, respectively.
The energy cost E
remoteComm,j
of a connector Conn
j
due to sending/receiving requests
and responses to/from the connectors of remote components can be estimated as
follows:
Eq. 4-16
e
j
is the number of requests sent over the network, while f
j
is the total number of
requests received over the network. tSize
m
and rSize
m
are the sizes of the mth
transmitted request and its received response, and rSize
n
and tSize
n
are the sizes of the
nth received request and its transmitted response, respectively. E
buffer,n
is the energy
( ) ( )
, , , , ,
1 1
c d
j j
com mW ithCom p j from Com p m toComp m toComp n fromCom p n
m n
E E E E E
= =
= + + +
∑ ∑
( ) ( ) ( )
( ) ( )
( )
,
1
,
1

e
j
remoteComm j m m
m
f
j
n n buffer n
n
E tSize tEC tS rSize rEC rS
rSize rEC rS tSize tEC tS E
=
=
= × + + × + +
× + + × + +
∑
∑
42
cost of buffering the nth received request. The other parameters are the same as those
in Equation 4-8.
The energy cost E
localComm,j
of a connector Conn
j
caused by sending/receiving
requests and responses to/from the connectors of local components can be calculated
as follows:
Eq. 4-17
g
j
is the total number of requests sent locally, and h
j
is the total number of requests
received locally. E
localTrans,m
and E
localReceiv,m
represent the energy costs of sending
the mth request and receiving its response, whereas E
localReceiv,n
and E
localTrans,n
are
the energy consumption of receiving the nth request and sending its response,
respectively. E
buffer,n
is the energy cost of buffering the nth received request.
Similar to the client-server style, as a connector transfers execution control to its
attached component by passing a request or response to that component, the energy
cost E
coordin,j
of connector Conn
j
due to performing its coordination service is already
captured by its energy cost E
commWithComp,j
. For example, if a connector and its
attached component are running as separate processes (or threads), execution control
between them is supported by an IPC (or thread signal) mechanism, whose energy
consumption is already included in E
commWithComp,j
.
( ) ( )
, , , , , ,
1 1
g h
j j
localCom m j localTrans m localReceiv m localReceiv n localTrans n buffer n
m n
E E E E E E
= =
= + + + +
∑ ∑
43
According to the characteristics of a connector in performing its conversion service,
the conversion cost E
conver,j
of a connector Conn
j
can be calculated as follows:
Eq. 4-18
e
j
is the number of requests sent remotely, and f
j
is the total number of requests
received over the network. E
mar,m
and E
unmar,m
are the energy costs of marshalling the
mth request and unmarshalling its received response, respectively. E
unmar,n
and E
mar,n
represent the energy consumption of unmarshalling the nth received request and
marshalling its response.
Finally, the energy cost E
facili,j
of a connector Conn
j
incurred by performing its
facilitation service can be quantified as follows:
Eq. 4-19
E
remoteConn
and E
localConn
are the constant energy costs due to establishing a single
connection with another remote or local connector, respectively. Num
remoteConns,j
and
Num
localConns,j
are the numbers of remote and local connections established,
respectively.
( ) ( )
, , , , ,
1 1
e f
j j
conver j mar m unmar m unmar n mar n
m n
E E E E E
= =
= + + +
∑ ∑
( ) ( )
, , , facili j remoteConn remoteConns j localConn localConns j
E E Num E Num = × + ×
44
4.2.3 C2 Style
The C2 architectural style supports large-grain reuse and flexible composition of
system components by enforcing substrate independence [72]. Figure 4-3 depicts an
example of a distributed software architecture built using the C2 style.
A C2 component has the following behaviors in communicating with its attached C2
connectors:
1. A C2 component can asynchronously receive request events from and produce
notification events to its bottom C2 connector, and asynchronously receive notifi-
cations from and send requests to its top C2 connector.
Figure 4-3: A distributed C2 architecture.
Host 1
Host 2
Legend
Comp 3 Comp 4
Broadcasting
C2 Connector
Broadcasting C2 Conn
Comp 2
Comp 1
Requests
Notifications
Bottom
Interface
Top
Interface
45
On the other hand, a C2 connector has the following behaviors in performing its
communication, coordination, conversion, and facilitation services:
Communication
1. A C2 connector asynchronously receives notifications from its top components or
(remote or local) top C2 connectors, and broadcasts them to its bottom compo-
nents or bottom C2 connectors.
2. A C2 connector also asynchronously receives requests from its bottom compo-
nents or bottom C2 connectors, and broadcasts them to its top components or top
C2 connectors.
Coordination
1. When a C2 connector broadcasts a request (notification) to its top (bottom) com-
ponents or connectors, it does not perform execution control transfer since C2 is
strictly asynchronous. This means that C2 connectors incur no coordination
energy cost.
Conversion
1. A C2 connector marshalls requests or notifications before sending them to remote
C2 connectors.
2. A C2 connector unmarshalls requests or notifications after receiving them over
the network.
3. A C2 connector performs an additional operation, known as domain translation
46
[72]. Domain translation is the transformation of requests issued by the connec-
tor’s attached components into the specific form understood by the recipient of
the requests, as well as the transformation of notifications received into the form
understood by the recipient of the notifications. Domain translation of a single
request or notification requires at least two steps, called message name matching
and parameter matching [72].
Facilitation
1. A C2 connector creates a connection object for receiving requests (notifications)
from and producing notifications (requests) to each of its remote bottom (top) C2
connectors.
Based on the above characterization of a component and a connector, the energy cost
E
commWithConn,i
of a component Comp
i
caused by sending/receiving requests and
notifications to/from its attached C2 connectors can be first calculated as follows:
Eq. 4-20
a
i
and b
i
are the total numbers of requests and notifications sent by the component,
while c
i
and d
i
represent the total numbers of requests and notifications received by
the component, respectively. E
toConn,k
represents the energy cost of sending the kth
request, while E
toConn,l
is the energy cost of sending the lth notification. E
fromConn,m
, , , , ,
1 1 1 1
a b c d
i i i i
commWithConn i toConn k toConn l fromConn m fromConn n
k l m n
E E E E E
= = = =
= + + +
∑ ∑ ∑ ∑
47
represents the energy cost of receiving the mth request, whereas E
fromConn,n
is the
energy cost of receiving the nth notification.
The energy cost E
commWithComp,j
of each C2 connector Conn
j
due to exchanging
requests and notifications with its attached components can be calculated as follows:
Eq. 4-21
e
j
is the total number of requests received from all of the connector’s bottom
components, and f
j
is the total number of notifications received from all of the
connector’s top components. g
j
is the total number of requests sent to all the
connector’s top components, whereas h
j
is the total number of notifications sent to all
the connector’s bottom components. E
fromComp,k
and E
buffer,k
represent the energy
consumption of receiving the kth request and buffering it, respectively. E
fromComp,l
and E
buffer,l
represent the energy consumption of receiving the lth notification and
buffering it. E
toComp,m
is the energy consumption of broadcasting the mth request to
all of the connector’s top components. E
toComp,n
is the energy consumption of
broadcasting the nth notification to all of the connector’s bottom components.
E
fromComp
and E
toComp
are determined based on the communication mechanism used
between the C2 connector and its attached components. For example, if IPC is used
( ) ( )
, , , , ,
1 1
, ,
1 1

e f
j j
commWithComp j fromComp k buffer k fromComp l buffer l
k l
g h
j j
toComp m toComp n
m n
E E E E E
E E
= =
= =
= + + + +
+
∑ ∑
∑ ∑
48
for the communication, E
toComp
is directly proportional to both the number of
receiving components and the size of a request or notification [71].
E
remoteComm,j
of a C2 connector Conn
j
due to exchanging requests and notifications
with remote C2 connectors can be estimated as follows:
Eq. 4-22
p
j
is the total number of requests received over the network through the connector’s
bottom interfaces, and q
j
is the total number of notifications received over the
network through the connector’s top interfaces. r
j
is the total number of requests sent
over the network through the connector’s top interfaces, whereas s
j
is the total
number of notifications sent over the network through the connector’s bottom
interfaces. rSize
k
and rSize
l
are the sizes of the kth request and lth response received
over the network, respectively. E
buffer,k
and E
buffer,l
are the energy consumption of
buffering the kth received request and lth received notification. tSize
m
and tSize
n
are
the sizes of the mth request and nth notification sent over the network. The other
parameters are the same as those in Equation 4-8.
( ) ( ) ( ) ( )
( ) ( )
, , ,
1 1
1 1

p q
j j
remoteComm j k buffer k l buffer l
k l
r s
j j
m n
m n
E rSize rEC rS E rSize rEC rS E
tSize tEC tS tSize tEC tS
= =
= =
= × + + + × + +
× + + × +
∑ ∑
∑ ∑
49
E
localComm,j
of a C2 connector Conn
j
caused by sending/receiving requests and
notifications to/from local C2 connectors can be calculated as follows:
Eq. 4-23
t
j
is the total number of requests received from local C2 connectors through the
connector’s bottom interfaces, and u
j
is the total number of notifications received
from local C2 connectors through the connector’s top interfaces. v
j
is the total number
of requests sent to local C2 connectors through the connector’s top interfaces, and w
j
is the total number of notifications sent to local C2 connectors through the
connector’s bottom interfaces. E
localReceiv,k
and E
localReceiv,l
are the energy costs of
receiving the kth request and lth notification from local C2 connectors, respectively.
E
buffer,k
and E
buffer,l
are the energy consumption of buffering the kth received request
and lth received notification. Finally, E
localTrans,m
and E
localTrans,n
are the energy
costs of sending the mth request and nth notification to local C2 connectors,
respectively.
Based on the behaviors of a C2 connector in performing its conversion service, the
conversion energy cost E
conver,j
of a C2 connector Conn
j
can be calculated as follows:
( ) ( ) , , , , ,
1 1
, ,
1 1

t u
j j
localComm j localReceiv k buffer k localReceiv l buffer l
k l
v w
j j
localTrans m localTrans n
m n
E E E E E
E E
= =
= =
= + + +
+
∑ ∑
∑ ∑
50
Eq. 4-24
p
j
and q
j
are the total numbers of requests and notifications to be unmarshalled,
whereas r
j
and s
j
are the total numbers of requests and notifications to be marshalled,
respectively. E
unmar,k
and E
unmar,l
are the energy costs of unmarshalling the kth
request and lth notification, respectively. E
mar,m
and E
mar,n
represent the energy costs
of marshalling the mth request and nth notification, respectively. t
j
and u
j
are the total
numbers of requests and notifications received by the connector, respectively.
E
nMatch,x
and E
pMatch,x
are the energy costs of message name matching and parameter
matching for the xth request received, respectively. E
nMatch,y
and E
pMatch,y
are the
energy costs of message name matching and parameter matching for the yth received
notification, respectively
Since a C2 connector only broadcasts requests and notifications to its top and bottom
interfaces, there is essentially no facilitation cost associated with the routing of
messages (beyond the communication cost of sending and receiving). This contrasts
with other styles in which connectors may perform additional services such as event
filtering. However, as discussed previously, C2 connectors incur a facilitation cost for
( ) ( )
, , , , ,
1 1 1 1
, , , ,
1 1

p q r s
j j j j
conver j unmar k unmar l mar m mar n
k l m n
t u
j j
nMatch x pMatch x nMatch y pMatch y
x y
E E E E E
E E E E
= = = =
= =
= + + + +
+ + +
∑ ∑ ∑ ∑
∑ ∑
51
establishing connections with remote C2 connectors. Therefore, the facilitation
energy cost E
facili,j
on a C2 connector Conn
j
can be calculated as follows:
Eq. 4-25
E
remoteConn
is the constant energy cost due to establishing a single connection with a
remote C2 connector. Num
remoteConns,j
is the number of remote connections
established.
4.2.4 Publish-Subscribe Style
The publish-subscribe (pub-sub) style reduces coupling by providing transparency
and anonymity of component identities and locations. Figure 4-4 shows an example
of a distributed software system designed using the pub-sub style.
Components in the pub-sub style can become a publisher, or a subscriber, or both.
Publishing or subscribing components have the following characteristics in
communicating with their attached pub-sub connectors:
1. A subscriber should first declare the events it wishes to receive by sending sub-
scriptions to its attached pub-sub connector, and then can receive published events
asynchronously from its attached connector. In addition, a subscriber can send
unsubscription messages to its attached connector for unsubscribing from a cer-
tain kind of events.
2. A publisher can continuously and asynchronously publish events to its attached
, , facili j remoteConn remoteConns j
E E Num = ×
52
pub-sub connector. It may also advertise events that it could potentially publish in
the future.
On the other hand, pub-sub connectors have the following characteristics in
performing their communication, coordination, conversion, and facilitation services:
Communication
1. A pub-sub connector receives and buffers (un)subscriptions from its attached sub-
scribers or other (remote or local) pub-sub connectors.
2. A pub-sub connector forwards (un)subscriptions received from its attached sub-
Figure 4-4: A distributed Publish-Subscribe architecture.
Legend
Host 1
Host 2
Publisher Subscriber
Pub-Sub Connector
Pub-Sub Connector
Subscriber
Publisher
Publish
Coordinate
Notification
Buffer
Event
Notification
53
scribers to other pub-sub connectors, so that they can also process those (un)sub-
scriptions.
3. A pub-sub connector receives and buffers publications and advertisements from
its attached publishers or other pub-sub connectors, and forward them to its
attached subscribers or other pub-sub connectors having subscribers of those
events, which are retrieved from the connector’s subscription database.
Coordination
1. After retrieving a set of subscribers for an event, a pub-sub connector can provide
time decoupling by queueing the event internally for subscribers to retrieve on-
demand.
Conversion
1. A pub-sub connector marshalls events, advertisements, subscriptions, or unsub-
scriptions before sending them over the network.
2. A pub-sub connector unmarshalls events, advertisements, subscriptions, or unsub-
scriptions after receiving them over the network.
Facilitation
1. A pub-sub connector processes subscriptions and unsubscriptions for managing a
list of subscribers for a certain kind of events.
2. A pub-sub connector retrieves a set of subscribers for each published event from
its subscription database, and also performs delivery guarantees.
54
3. A pub-sub connector creates a connection object in order to exchange (un)sub-
scriptions or events with each of its connected local or remote pub-sub connec-
tors.
Based on the above characterization, we can first calculate the energy cost
E
commWithConn,i
of a component Comp
i
due to exchanging (un)subscriptions, events,
and advertisements with a pub-sub connector as follows:
Eq. 4-26
a
i
is the total number of events and advertisements sent by the component, and b
i
represents the total number of events and advertisements received by the component.
E
toConn,k
is the energy cost of sending the kth event or advertisement to the pub-sub
connector, while E
fromConn,l
is the energy cost of receiving the lth event or
advertisement from the connector. c
i
and d
i
are the numbers of subscriptions and
unsubscriptions sent by the component. E
subs,m
and E
unsubs,n
are the energy costs
incurred by sending the mth subscription and nth unsubscription to the pub-sub
connector.
The communication cost E
commWithComp,j
of a pub-sub connector Conn
j
incurred by
exchanging (un)subscriptions, events, and advertisements with its attached
components can be calculated as follows:
, , , , ,
1 1 1 1
a b c d
i i i i
commW ithConn i toConn k fromConn l subs m unsubs n
k l m n
E E E E E
= = = =
= + + +
∑ ∑ ∑ ∑
55
Eq. 4-27
e
j
is the total number of events and advertisements received from the connector’s
attached components, while f
j
is the total number of events and advertisements sent to
the connector’s attached components. E
fromComp,k
and E
buffer,k
are the energy costs of
receiving the kth event or advertisement from one of the connector’s attached
components and buffering it, while E
toComp,l
is the energy consumption of forwarding
the lth event or advertisement to all of its local subscribers. Note that E
toComp
is
directly proportional to the number of subscribers of a given event or advertisement.
g
j
and h
j
are the numbers of subscriptions and unsubscriptions received from the
connector’s attached components. E
rSubs,m
and E
rUnsubs,n
are the energy costs
incurred by receiving the mth subscription and nth unsubscription, whereas E
buffer,m
and E
buffer,n
are the energy consumption of buffering the mth subscription and nth
unsubscription, respectively.
The communication cost E
remoteComm,j
of a pub-sub connector Conn
j
caused by
sending/receiving events, advertisements, and (un)subscriptions to/from remote pub-
sub connectors can be estimated as follows:
( )
( ) ( )
, , , ,
1 1
, , , ,
1 1

e f
j j
commWithComp j fromComp k buffer k toComp l
k l
g h
j j
rSubs m buffer m rUnsubs n buffer n
m n
E E E E
E E E E
= =
= =
= + + +
+ + +
∑ ∑
∑ ∑
56
Eq. 4-28
p
j
is the total number of events and advertisements received over the network, and q
j
is the total number of subscriptions and unsubscriptions received over the network. r
j
is the total number of events and advertisements sent over the network, whereas s
j
is
the total number of subscriptions and unsubscriptions sent over the network. rSize
k
and rSize
l
are the sizes of the kth event or advertisement and lth subscription or
unsubscription received over the network, respectively. E
buffer,k
and E
buffer,l
are the
energy costs of buffering the kth event or advertisement and lth subscription or
unsubscription. tSize
m
and tSize
n
are the sizes of the mth event or advertisement and
nth subscription or unsubscription sent over the network. The other parameters are the
same as those in Equation 4-8.
We can calculate E
localComm,j
of a pub-sub connector Conn
j
due to exchanging events,
advertisements, and (un)subscriptions with local pub-sub connectors as follows:
Eq. 4-29
( ) ( ) ( ) ( )
( ) ( )
, , ,
1 1
1 1

p q
j j
remoteComm j k buffer k l buffer l
k l
r s
j j
m n
m n
E rSize rEC rS E rSize rEC rS E
tSize tEC tS tSize tEC tS
= =
= =
= × + + + × + +
× + + × +
∑ ∑
∑ ∑
( ) ( )
, , , , ,
1 1
, ,
1 1

t u
j j
localComm j localReceiv k buffer k localReceiv l buffer l
k l
v w
j j
localTrans m localTrans n
m n
E E E E E
E E
= =
= =
= + + +
+
∑ ∑
∑ ∑
57
t
j
and u
j
are the total numbers of events and advertisements, and subscriptions and
unsubscriptions received from local pub-sub connectors, respectively. v
j
and w
j
represent the total numbers of events and advertisements, and subscriptions and
unsubscriptions sent to local pub-sub connectors, respectively. E
localReceiv,k
and
E
localReceiv,l
are the energy costs of receiving the kth event or advertisement and lth
subscription or unsubscription from local pub-sub connectors. E
buffer,k
and E
buffer,l
are
the energy costs of buffering the kth event or advertisement and lth subscription or
unsubscription. E
localTrans,m
and E
localTrans,n
are the energy costs of sending the mth
event or advertisement and nth subscription or unsubscription to local C2 connectors,
respectively.
The energy cost E
coordin,j
of a pub-sub connector Conn
j
incurred by performing its
coordination service can be calculated as follows:
Eq. 4-30
x
j
is the total number of events received by the connector, and E
queue,m
represents the
energy cost due to queueing the mth event.
The conversion cost E
conver,j
of a pub-sub connector Conn
j
can be calculated as
follows:
, ,
1
x
j
coordin j queue m
m
E E
=
=
∑
58
Eq. 4-31
p
j
and q
j
are the total numbers of events and advertisements, and subscriptions and
unsubscriptions to be unmarshalled, whereas r
j
and s
j
are the total numbers of events
and advertisements, and subscriptions and unsubscriptions to be marshalled,
respectively. E
unmar,k
and E
unmar,l
are the energy costs of unmarshalling the kth event
or advertisement and lth subscription or unsubscription, respectively. E
mar,m
and
E
mar,n
represent the energy costs of marshalling the mth event or advertisement and
nth subscription or unsubscription, respectively.
Based on the characteristics of a pub-sub connector in performing its facilitation
service, the facilitation energy cost E
facili,j
of a pub-sub connector Conn
j
can be
calculated as follows:
Eq. 4-32
x
j
is the total number of events received by the connector, whereas y
j
and z
j
are the
numbers of subscriptions and unsubscriptions received by the connector, respectively.
E
route,k
is the energy cost of retrieving a set of subscribers for the kth event from a
, , , , ,
1 1 1 1
p q r s
j j j j
conver j unmar k unmar l mar m mar n
k l m n
E E E E E
= = = =
= + + +
∑ ∑ ∑ ∑
( )
( ) ( )
, , , , ,
1 1 1
, ,

x y z
j j j
facili j route k delivery k procSubs m procUnsubs n
k m n
remoteConn remoteConns j localConn localConns j
E E E E E
E Num E Num
= = =
= + + + +
× + ×
∑ ∑ ∑
59
subscription database, while E
delivery,k
is the energy consumption due to performing
delivery guarantees for the kth event. E
procSubs,m
and E
procUnsubs,n
represent the
energy consumption of processing the mth subscription and nth unsubscription,
respectively. E
remoteConn
and E
localConn
are the constant energy costs due to
establishing a single connection with a remote or local pub-sub connector,
respectively. Num
remoteConns,j
and Num
localConns,j
are the numbers of remote and local
connections established, respectively.
The additional energy cost parameters (e.g., E
subs
, E
unsubs
, E
procSubs
, etc.) described
in this section are also platform-specific. We will discuss how they are determined for
an actual platform in Section 4.3. and Section 6.1.
4.2.5 Pipe-and-Filter Style
In the pipe-and-filter style, a filter (component) reads streams of data from its input
pipes (connectors), processes them, and then produces streams of data to its output
pipes. Filters are independent of each other and may produce outputs before their
inputs are completely consumed. Figure 4-5 shows an example of a distributed
architecture designed with the pipe-and-filter style.
A filter has the following characteristics in communicating with its connected pipes:
1. A filter writes streams of data to all of its output pipes, and reads streams of data
from all the its input pipes.
60
One the other hand, a pipe has the following characteristics in performing its
communication, coordination, conversion, and facilitation services:
Communication
1. A pipe receives and buffers streams of data from all of its input filters or remote
input pipes.
2. A pipe forwards streams of received data to all of its output filters or remote out-
put pipes.
Coordination
1. A pipe does not perform a coordination service (i.e., execution control transfer) as
a pipe operates independently from its attached filters.
Conversion
1. If the data streams passed between two filters are typed, a pipe should perform
marshalling of the data streams before sending them over the network.
Figure 4-5: A distributed Pipe-and-Filter architecture.
Host 1
Host 2
Source
Filter
Pipe
Filter
Pipe
Filter
Pipe
Sink
Filter
Streams of data
Streams of data
61
2. If the data streams passed between two filters are typed, a pipe also performs
unmarshalling of the data streams after receiving them over the network.
3. A pipe performs the conversion of the data streams if two filters do not use the
same data format.
• Facilitation
1. A pipe creates a connection object for receiving (sending) streams of data from
(to) each remote pipe.
Based on the above characterization, we can first calculate the energy cost
E
commWithConn,i
of a filter Comp
i
due to sending streams of output data to and
receiving streams of input data from its attached pipes as follows:
Eq. 4-33
a
i
is the total number of data transmissions through the filter’s write interfaces, and b
i
represents the total number of data receipts through the filter’s read interfaces.
E
toConn,k
is the energy cost of the kth data transmission, while E
fromConn,l
is the energy
cost of the lth data receipt.
The energy cost E
commWithComp,j
of a pipe Conn
j
caused by receiving streams of data
from and sending streams of data to its attached filters can be calculated as follows:
, , ,
1 1
a b
i i
commWithConn i toConn k fromConn l
k l
E E E
= =
= +
∑ ∑
62
Eq. 4-34
c
j
is the total number of data receipts from all the filters connected through the pipe’s
source interfaces, while d
j
is the total number of data transmissions to all of the filters
connected through the pipe’s sink interfaces. E
fromComp,m
and E
buffer,m
are the energy
costs of the mth data receipt and buffering, respectively. E
toComp,n
is the energy
consumption of the nth data transmission.
The remote communication cost E
remoteComm,j
of a pipe Conn
j
caused by exchanging
streams of data with remote pipes can be calculated as follows:
Eq. 4-35
e
j
is the total number of data receipts over the network, and f
j
is the total number of
data transmissions over the network. rSize
m
is the data size for the mth receipt over
the network, whereas tSize
n
is the data size for the nth transmission over the network.
E
buffer,m
is the energy cost of buffering the mth received data. The other parameters
are the same as those in Equation 4-8.
( )
, , , ,
1 1
c d
j j
commWithComp j fromComp m buffer m toComp n
m n
E E E E
= =
= + +
∑ ∑
( )
( )
( )
, ,
1 1
e f
j j
remoteComm j m buffer m n
m n
E rSize rEC rS E tSize tEC tS
= =
= × + + + × +
∑ ∑
63
Since pipes are not connected locally with each other, the energy cost E
localComm,j
of a
pipe Conn
j
resulting from exchanging records with local pipes is not incurred in the
pipe-and-filter style.
In addition, as a pipe does not provide a coordination service, the energy cost
E
coordin,j
of a pipe Conn
j
caused by performing its coordination service does not need
to be modeled.
If the data streams exchanged between two filters are typed or the two filters do not
use the same data format, the conversion cost E
conver,j
of a pipe Conn
j
should be
considered and can be calculated as follows:
Eq. 4-36
c
j
is the total number of data receipts from all the filters connected through the pipe’s
source interfaces. e
j
is the total number of data receipts over the network, whereas f
j
is
the total number of data transmissions over the network. E
fConver,k
is the energy cost
due to performing data stream format conversion for the kth data receipt. E
unmar,l
is
the unmarshalling energy cost for the lth data receipt, and E
mar,m
represents the
marshalling energy cost for the mth data transmission.
, , , ,
1 1 1
c e f
j j j
conver j fConver k unmar l mar m
k l m
E E E E
= = =
= + +
∑ ∑ ∑
64
The energy cost E
facili,j
of a pipe Conn
j
incurred by performing its facilitation service
can be calculated as follows:
Eq. 4-37
E
remoteConn
is the constant energy cost resulting from establishing a single connection
with a remote pipe, and Num
remoteConns,j
is the number of remote connections
established.
4.2.6 Energy Cost Comparisons of Architectural Styles
In this section we discuss the comparisons of our selected five architectural styles
with respect to their induced energy costs. For this, we first identify a distributed
system’s following properties for comparing each pair of styles:
• Destinations of a message (e.g., the destination components of a given message
may be running on the same host or on the different hosts)
• Number of destinations of a message
• Numbers of remote/local data transmissions and receipts
• Average size of a message
• Interaction frequency between components
• Number of different message types
Note that each of the above comparison dimensions is not applicable to every style
pair. The comparisons of architectural styles discussed in this section will be verified
through the empirical evaluations discussed in Chapter 6.
, , facili j remoteConn remoteConns j
E E Num = ×
65
4.2.6.1 Client-Server (or Peer-to-Peer) vs. Publish-Subscribe Styles
The client-server (or peer-to-peer) style is based on point-to-point interactions
between components. Therefore, if the destinations of a message are usually
components running on a few hosts, the client-server style requires more data to be
exchanged over the network because the client-server style transmits a message to
each destination component separately while the publish-subscribe style requires only
one transmission of a message to each target host. This indicates that the remote
communication energy cost (i.e., E
remoteComm
of Equations 4-8 and 4-9) of a client’s
and server’s connectors would be larger than that (i.e., E
remoteComm
of Equation 4-28)
of publish-subscribe connectors. However, publish-subscribe connectors incur a
higher facilitation energy cost (i.e., E
facili
of Equation 4-32) than a client’s and
server’s connectors (i.e., E
facili
of Equation 4-13) because the publish-subscribe style
has the additional overhead of managing a list of subscribers and retrieving them for
each event. Note that this facilitation cost in the publish-subscribe style becomes
larger as the number of different message types increases. Consequently, the client-
server style will be less energy-efficient if its overhead due to remote exchange of
more data is larger than the facilitation cost in the publish-subscribe style.
On the other hand, if the destination components of a message are usually running on
different hosts, or the number of destinations of a message is usually 1, the client-
server style is more energy-efficient because (1) the total number of messages
exchanged among components and connectors is almost the same in the two styles,
66
but (2) the publish-subscribe style incurs a larger facilitation energy overhead E
facili
due to managing subscribers and retrieving them for each event. In both of the above
cases, the difference in the energy costs of the two styles becomes larger as the
interaction frequency between components or average size of a message increases.
4.2.6.2 Client-Server (or Peer-to-Peer) vs. C2 Styles
A C2 connector broadcasts a request (notification) to all of its top (bottom) interfaces,
but requires only one transmission of a given message to each connected host.
Consequently, if the destinations of a message are a large subset of the system’s
constituent components that are running on different hosts, the C2 style is more
energy-efficient than the client-server (or peer-to-peer) style. This is because the
client-server style is based on point-to-point interactions between components and
thus requires more data to be exchanged. In turn, this incurs a larger remote
communication cost (i.e., E
remoteComm
of Equations 4-8 and 4-9) of a client’s and
server’s connectors than that (i.e., E
remoteComm
of Equations 4-22) of C2 connectors.
On the other hand, if the destinations of a message are usually a small subset of the
system’s constituent components, the client-server style would incur less energy
consumption because the C2 style requires more data to be exchanged both locally
and remotely among components and connectors. This indicates that the local and
remote communication energy costs (i.e., E
commWithComp
of Equation 4-21,
E
remoteComm
of Equation 4-22, and E
localComm
of Equation 4-23) of C2 connectors
67
would be larger than those (i.e., E
commWithComp
of Equation 4-7, E
remoteComm
of
Equations 4-8 and 4-9, and E
localComm
of Equation 4-10) of a client’s and server’s
connectors. In both of the above cases, the difference in the energy costs of the two
styles grows as the interaction frequency between components or average size of a
message increases.
4.2.6.3 Client-Server vs. Peer-to-Peer Styles
The main difference between the client-server and peer-to-peer styles is that a
component in the peer-to-peer style can provide services as well as invoke services
provided by other components, which indicates that there are no separations of server
and client components unlike the client-server style. Consequently, the number of
remote transmissions and receipts in the client-server style would be different from
that of the peer-to-peer style because a remote (local) interaction in the client-server
style may change to a local (remote) interaction in the peer-to-peer style. For
example, consider the distributed sensor application designed with the client-server
style shown in Figure 1-1 of Chapter 1. As discussed in Chapter 1, each fire alarm
requires the remote transmission of two requests from Host 2 because the client-
server connector on Host 2 transmits a request (received from its local
FireAlarmReceiver component) to the FireAlarmAnalyzer and AlarmLogger
components on Host 1 separately. On the other hand, if the above application is
designed with the peer-to-peer style, the FireAlarmReceiver on Host 2 sends a single
alarm request to the FireAlarmAnalyzer through its peer-to-peer connector. In turn,
68
the FireAlarmAnalyzer forwards the alarm request to the AlarmLogger component,
while analyzing the alarm. This means that the FireAlarmAnalyzer provides an
analyzing service for the FireAlarmReceiver as well as invokes a logging service
provided by the AlarmLogger. Consequently, a remote interaction between the
FireAlarmReceiver and the AlarmLogger in the client-server style changes to a local
interaction between the FireAlarmAnalyzer and the AlarmLogger in the peer-to-peer
style.
Therefore, if the number of remote transmissions and receipts in the peer-to-peer style
is less than that in the client-server style, the peer-to-peer style would be more energy-
efficient because the remote communication cost (i.e., E
remoteComm
of Equation 4-16)
of the peer-to-peer style’s connectors is less than a client’s and server’s connectors
(i.e., E
remoteComm
of Equations 4-8 and 4-9). Otherwise, the client-server style incurs
less energy consumption. In these two cases, the energy consumption difference
between the two styles becomes larger as the interaction frequency between
components or average size of a message increases.
4.2.6.4 Publish-Subscribe vs. C2 Styles
A C2 connector broadcasts a request (notification) event to all of its top (bottom)
interfaces, while a publish-subscribe connector routes an event to its subscribers only.
Therefore, if the destinations of a message are usually most of the system’s
constituent components and these destination components are running on different
69
hosts, the C2 style requires less energy consumption because (1) the amount of data
exchanged locally and remotely are approximately the same in both styles, but (2) the
publish-subscribe style causes more facilitation energy overhead (i.e., E
facili
of
Equation 4-32) due to managing a list of subscribers and retrieving them for each
published event, which is not incurred in the C2 style.
On the other hand, if the destinations for a message are usually a small set of
components, the C2 style causes more data to be exchanged both locally and
remotely. Therefore, the C2 style consumes more energy if the energy overhead (i.e.,
E
commWithComp
of Equation 21, E
remoteComm
of Equation 22, and E
localComm
of
Equation 23) due to local and remote exchange of more data in the C2 style is larger
than the increased facilitation energy overhead (i.e., E
facili
of Equation 4-32) in the
publish-subscribe style. In the above both cases, the difference in the energy costs of
the two styles is proportional to both the interaction frequency between components
and the average size of a message.
4.2.6.5 C2 vs. Pipe-and-Filter Styles
In the pipe-and-filter style, a pipe may transmit data streams separately to each of the
destination components running on a remote host, while a C2 connector requires only
one transmission of a given message to each connected host. Therefore, if the
destinations of a message are usually most of the system’s constituent components
and these destination components are being executed on different hosts, the C2 style
70
would be more energy-efficient because a C2 connector incurs less remote
communication energy overhead (i.e., E
remoteComm
of Equation 4-22) than a pipe (i.e.,
E
remoteComm
of Equation 4-35).
However, if the destinations of a message are usually a small subset of the system’s
constituent components, the pipe-and-filter style requires less energy consumption as
the C2 style exchanges more data both locally and remotely, which incurs more local
and remote communication energy overhead in a C2 connector. In both of the above
cases, the energy cost difference between the two styles becomes larger as the
interaction frequency between components or the average size of a message
increases. Note that the above comparisons are only applicable to distributed
applications that can be designed with both the pipe-and-filter and the C2 styles. In
other words, the system’s constituent components (i.e., filters) in the pipe-and-filter
style should be the same as that in the C2 style for comparing their induced energy
costs.
4.3 Mappings to the Platform Constructs
The equations given in Section 4.2 provide a symbolic representation of architectural
style-induced energy costs on a distributed system, and serve as the basis for
analyzing the differences among styles with respect to energy consumption. However,
in order to determine the actual values of the parameters given in Section 4.2, the
energy consumption model of a given style must be mapped to a specific middleware
71
platform. This is accomplished by determining how each parameter in the energy cost
model is realized via components’ and connectors’ interfaces provided by a given
platform. In this section, we demonstrate this process by detailing how the energy
consumption models for the client-server, C2, and publish-subscribe styles can be
mapped onto the Java RMI, Prism-MW [39], and TAO CORBA [70] middleware
platforms, respectively. The process for the remaining styles, as well as other
middleware platforms, is analogous.
4.3.1 Client-Server Style
To map the client-server energy consumption model to a Java RMI-based
implementation, similar to the one shown in Figure 4-1, we must first determine the
sequence of interfaces’ invocations (e.g., client’s and server’s interfaces, and stub’s
and skeleton’s interfaces) performed on the Java RMI run-time environment to
accomplish the tasks associated with each cost given in Section 4.2.1. For example,
the energy cost parameter E
remoteConn
in the facilitation cost E
facili
of the client-server
style is due to the task of establishing a single remote connection. In Java RMI, this is
accomplished via the following sequence of interfaces’ invocations: (1) servers
register with the RMI naming service by invoking the bind interface of the Naming
component, (2) clients search the registry by invoking the lookup interface of the
Naming component and receive an object handle. Therefore, by measuring the energy
costs of invoking the bind and lookup interfaces (using the procedure described in
72
Section 6.1.2), the energy cost parameter E
remoteConn
, as implemented in Java RMI,
can be determined.
A similar process is followed to determine the values of the remaining parameters
given in the client-server energy consumption model. The energy costs E
toConn
and
E
fromConn
on a client, and the energy costs E
toComp
, E
fromComp
, E
mar
, E
unmar
, and
E
remoteComm
on a client’s connector (which is a RMI stub in this scenario) are incurred
when a client invokes one of the interfaces provided by a remote server via the
client’s stub. Therefore, by measuring the energy consumption of invoking the stub’s
interfaces, the values of these parameters can be measured. The energy costs E
toComp
,
E
fromComp
, E
mar
, E
unmar
, and E
remoteComm
on a server’s connector (which is a RMI
skeleton in this example) and the energy costs E
toConn
and E
fromConn
on a server
component are incurred when the RMI skeleton receives a remote request and
forwards it to the server, and then receives a response from the server and forward it
to a remote client’s stub. Again, by profiling the energy consumption of the RMI
skeleton’s interfaces, the values of these parameters can be obtained.
4.3.2 C2 Style
For the C2 style, we show the mapping of the energy consumption model onto a
lightweight, component-based middleware platform called Prism-MW [39]. Prism-
MW provides implementation-level support for realizing architectural elements and
various architectural styles.
73
In Prism-MW, the top and bottom interfaces of C2 components and connectors (recall
Figure 4-3) are implemented as request ports and reply ports. The energy cost
parameter E
remoteConn
in the facilitation energy cost due to the establishment of a
single remote connection is incurred when a C2 connector invokes the connect
interface of a request port, which establishes a socket communication. The energy
cost E
toConn
on a C2 component corresponds to the invocation of a component’s send
interface, which is provided by the middleware and places the event sent by the
component in a queue. A C2 connector incurs the cost E
fromComp
when the
middleware invokes its handle interface, which is used by a connector to receive
events. Finally, the energy costs E
mar
, E
unmar
, and E
remoteComm
on a connector
correspond to sending/receiving an event to/from other remote C2 connectors via the
send/receive interfaces of the connector’s port.
4.3.3 Publish-Subscribe Style
For the publish-subscribe style, consider the TAO realtime ORB [70], which is an
open-source implementation of Realtime CORBA. In [55] Schmidt et al. discuss how
they support publish-subscribe interactions between CORBA components on top of
the TAO middleware. The TAO publish-subscribe infrastructure has an event channel
running on each host. An event channel (1) consists of admin module and dispatching
module; (2) interacts with other event channels via CORBA; and (3) can be
considered as a connector for its local publishers and subscribers.
74
The energy cost parameters E
rSubs
and E
rUnsubs
on a connector due to receiving
(un)subscriptions from its attached subscribers, and E
procSubs
and E
procUnsubs
in the
connector’s facilitation cost are incurred when the admin module receives
(un)subscriptions from subscribers and processes them via its subscription interface.
The parameter E
route
in the connector’s facilitation cost corresponds to the invocation
of the admin module’s interface that retrieves the set of subscribers for each published
event from its subscription database. The parameters E
toComp
and E
remoteComm
on the
connector are incurred when the dispatching module’s interface, which pushes each
published event to its local and remote subscribers, is invoked. The parameters
E
toConn
on a publishing component corresponds to the invocation of the publisher’s
interface that sends an event to its local event channel. Finally, the parameter
E
fromConn
on a subscriber is incurred when the subscriber’s interface, which receives
an event from its local event channel, is executed.
4.4 Characterizing the System’s Properties
Once the energy consumption induced by an architectural style is modeled and
mapped to a target platform, it is necessary to capture a set of properties for a target
component-based distributed system in order to get the actual energy consumption
value resulting from each of the target system’s candidate architectural styles. For
this, the following two properties in addition to those presented in Section 4.2.6
should be characterized during the system’s design-time:
75
• The system’s constituent components and connectors, as well their configuration
• The system’s deployment architecture, which is the allocation of the system’s com-
ponents and connectors to its hardware hosts
As an example, consider the distributed sensor application designed with the publish-
subscribe style shown in Figure 1-1. There are five components and three publish-
subscribe connectors, which are running on three hosts. The types of messages are
fire alarm, intrusion alarm, fire sensor activation, intrusion sensor activation, and
subscriptions for these alarm and sensor activation messages. The destination
components for a fire alarm message are FireAlarmAnalyzer and AlarmLogger
components, while an intrusion alarm message has the destinations of
IntrusisonAlarmAnalyzer and AlarmLogger components. The destination of a fire
sensor activation message is the FireAlarmReceiver component, whereas an intrusion
sensor activation has the IntrusionAlarmReceiver destination component. Finally, the
sizes and frequencies of the above message types can be determined based on the
domain knowledge, and be also varied during the system’s design-time.
76
CHAPTER 5: Energy Cost Framework for Distributed
Java-Based Systems
In this chapter, we first overview our framework that estimates the energy
consumption of a component-based distributed system implemented in Java, and then
detail how the framework can model a system’s overall energy cost at the level of its
components. We then discuss how our framework can be used both during system
construction-time and during runtime, and finally suggest a number of applications
for the framework.
As discussed in Chapter 4, our style energy cost framework is used for estimating the
energy consumption resulting from each candidate style of a target distributed system
by modeling each style’s induced energy cost, mapping it to a target platform (e.g.,
middleware, JVM, hardware, etc.), and characterizing the system’s properties during
design-time. During construction-time, an engineer would then implement a target
distributed system based on various design decisions including an architectural style,
which are made at design-time. The estimation framework presented in this chapter
will be then used for characterizing the energy cost of each component’s
implementation during construction-time and refining it by monitoring a small
number of the system’s parameters (e.g., size of data exchanged between components,
inputs to a component’s interfaces, invocation frequency of each interface, etc.)
during runtime.
77
5.1 Overview of the Framework
Our framework models a distributed system’s overall energy consumption at the level
of its software components. A component is a unit of computation and state. In a
Java-based application, a component may comprise a single class or a cluster of
related classes. Modeling the system’s energy consumption in terms of software
components will enhance our ability to estimate more accurately any energy
consumption variations that are caused by system adaptation (e.g., temporarily
unloading components that consume a lot of energy).
In a distributed system, the energy consumption of a software component consists of
its computational and communication energy costs. The computational cost is mainly
due to CPU processing, memory access, I/O operations, and so forth, while the
communication cost is mainly due to the data exchanged between components over
the network. In order to accurately determine the computational and communication
energy costs of a component, we focus on the component’s constituent interfaces. A
component’s interface corresponds to a service provided by that component to other
components. In addition to the above two energy costs, our framework considers the
additional energy cost incurred by an OS and an application’s runtime platform (e.g.,
JVM) in the process of managing the execution of software components. We refer to
this cost as infrastructure energy overhead.
78
During system construction-time, our framework can estimate the computational and
communication energy costs of each component and the infrastructure energy
overhead in a target distributed system by predicting a small number of the system’s
parameters (e.g., size of data exchanged between components over the network,
inputs to a component’s interfaces, invocation frequency of each interface, etc.), and
then calculate the distributed system’s overall energy consumption by aggregating the
energy costs of all the components and the infrastructure energy overhead. However,
if the system’s parameters predicted during construction-time are not close to the
system’s runtime behaviors, construction-time energy consumption estimates from
our framework would be inaccurate compared with the system’s actual energy cost.
To address this issue, our framework provides an efficient monitoring mechanism for
keeping track of the system’s parameters, and consequently supports the refinement
of construction-time energy estimates during runtime.
5.2 Energy Consumption Models
In this section, we present our approach to modeling the computational and
communication energy costs of a single component, and the infrastructure energy
overhead in a component-based distributed system implemented in Java.
5.2.1 Computational Energy Cost
While there are many ways of implementing an interface and binding it to the caller
in Java (e.g., RMI, event exchange), in the most prevalent case an interface
79
corresponds to a method. In Section 5.2.2 we discuss our framework’s ability to
capture other forms of interface implementation and binding (e.g., data serialization
over sockets).
As an example, Figure 5-1 highlights a component c
1
on host H
1
, c
1
’s provided
interfaces, and the invocation of those interfaces by remote components. Given the
computational energy consumption iCompEC resulting from invoking an interface I
i
,
and the total number b
i
of invocations for interface I
i
, we can calculate the
computational energy consumption of a component c
1
with n interfaces (expressed in
Joule or J) as follows:
Eq. 5-1
Figure 5-1: Interactions among distributed components.
H
1
C
1
…
I
1
I
2
I
n
C
4
C
2
C
6
C
3
C
5
C
7
H
2
H
3
H
4
H
1
C
1
…
I
1
I
2
I
n
C
4
C
2
C
6
C
3
C
5
C
7
H
2
H
3
H
4
1
1 1
( ) ( , )
i
b
n
i
i j
cCompEC c iCompEC I j
= =
=
∑∑
80
In this equation, iCompEC(I
i
,j), the computational energy cost due to the j
th
invocation of I
i
, may depend on the input parameters’ values of I
i
and may be
different for each invocation. We observe that a good estimate of a component’s
energy consumption directly depends on our ability to accurately estimate the energy
consumption resulting from invoking the component’s interfaces (i.e., the
iCompEC(I
i
,j) variable in Equation 5-1).
In Java, the effect of invoking an interface can be expressed in terms of the execution
of the 256 Java bytecode types, and of the native methods provided by the JVM. Java
bytecodes are platform-independent codes interpreted by JVM’s interpreter, while
native methods are library functions (e.g., java.io.FileInputStream’s
read() method) provided by JVM. Native methods are usually implemented in C
and compiled into dynamic link libraries, which are automatically installed when the
JVM is installed. JVM also provides a mechanism for synchronizing multiple threads
via an internal implementation of a monitor. In a multi-threaded environment,
monitor acquire/release operations are executed internally within a JVM as a result of
invoking a synchronized method. Since each monitor acquire operation should be
paired with a monitor release operation, we consider one monitor acquire operation
and its corresponding monitor release operation as one monitor operation in our
framework. Based on the 256 bytecodes, m native methods, and monitor operations
that are available on a given JVM, we can estimate the energy consumption
iCompEC(I
i
,j) of invoking an interface on that JVM as follows:
81
Eq. 5-2
where bNum
k,j
and fNum
l,j
are the numbers of each type of bytecode and native
method, and mNum
j
is the number of monitor operations executed during the j
th
invocation of I
i
. bEC
k
, fEC
l
, and mEC represent the energy consumption of executing
the type of bytecode, native method, and a monitor operation, respectively. Unless
two platforms have the same hardware configurations, JVMs, and OSs, the energy
values of bEC
k
, fEC
l
, and mEC on the two platforms will likely be different. We will
explain how these values can be obtained for an actual host in Chapter 6.
As a simple illustration of applying the above formula, Figure 5-2 shows a partial
Java implementation of a Stack class (left), and a sequence of bytecodes executed
for the invocation of its push interface when the stack is not full (right). The right
side of Figure 5-2 also shows the energy consumption value for each bytecode
executed during push’s invocation. These values are used for illustration here; they
were obtained by profiling a particular implementation of the JVM on a specific
hardware platform in the manner detailed in Chapter 6. Since there are no native
method calls and monitor operations within the implementation of the push method,
the energy consumption per its invocation can be calculated from Equation 5-2 as
256
, ,
1 1
( , )
m
i k j k l j l j
k l
iCompEC I j bNum bEC fNum fEC mNum mEC
= =
   
    = × + × + ×
   
   
∑ ∑
82
We should note that the same sequence of bytecodes will be executed for each
invocation of push interface if the stack is not full. Clearly this is not the case with a
great majority of Java methods (e.g., those containing loops and/or conditional
statements). We elaborate on how this issue is handled by our framework in Section
5.3.
3 3 _ _1

50.9568
pushEC aload getfield iload iastore dup if icmpeq iconst
iadd putfield return
J μ
= ∗ + ∗ + + + + + +
+ +
=
Figure 5-2: push interface of the Stack component and bytecodes executed per push invocation.
class Stack {
int[] data;
int top;
public Stack(int size) {
data = new int[size];
top=0;
}
public short push(int i) {
if(top == data.length)
return 0;
data[top] = i ;
top++;
return 1;
}
…
}
A sequence of bytecodes executed per push invocation:
- aload: (energy cost: 3.2734 μJ)
- getfield: loading the value of a field (top) into
an operand stack (energy cost: 4.5098 μJ)
- aload: (energy cost: 3.2734 μJ)
- getfield: loading the value of a field (data.length) into
an operand stack (energy cost: 4.5098 μJ)
- if_icmpeq: comparing a top value with a data.length
value (energy cost: 3.7744 μJ)
- iload: loading a local integer variable i into
an operand stack (energy cost: 3.1384 μJ)
-iastore: storing a local variable i into an integer
array data (energy cost: 3.5786 μJ)
- aload: (energy cost: 3.2734 μJ)
- dup: (energy cost: 2.8563 μJ)
- getfield: loading the value of a field (top) into
an operand stack (energy cost: 4.5098 μJ)
- iconst_1: (energy cost: 2.7898 μJ)
-iadd: adding 1 into the loaded value
(energy cost: 2.9485 μJ)
- putfield: storing the added value into a field (top)
(energy cost: 4.6758 μJ)
- return: terminating push method by returning a value
(energy cost: 3.8454 μJ)
83
5.2.2 Communication Energy Cost
There are two main categories of inter-component communication: local
communication (among components in the same address space), and remote
communication (among components in different address spaces). We first consider
local communication. When components are part of the same JVM process but
running in independent threads, the communication among the threads is generally
achieved via native method calls (e.g., java.lang.Object’s notify()
method); recall that a component’s reliance on native method calls has already been
accounted for in calculating its computational cost from Equation 5-2. When
components run as separate JVM processes on the same host, Java sockets are usually
used for their communication. Given that JVMs generally use native methods (e.g.,
java.net.SocketInputStream’s read() method) for socket
communication, this is also captured by each component’s computational cost.
In remote communication, the transmission of messages via network interfaces
consumes significant amounts of energy. Given the communication energy
consumption iCommEC due to invoking an interface I
i
, and the total number b
i
of
invocations for that interface I
i
, we can calculate the overall communication energy
consumption of a component c
1
with n interfaces (expressed in Joule) as follows:
Eq. 5-3
1
1 1
( ) ( , )
i
b
n
i
i j
cCommEC c iCommEC I j
= =
=
∑∑
84
In this equation, iCommEC(I
i
,j), the communication energy cost incurred by the j
th
invocation of I
i
, depends on the amount of data transmitted or received during the
invocation and might be different for each invocation. In the rest of this section, we
explain how we have modeled iCommEC(I
i
,j).
We focus on modeling the energy consumption due to remote communication based
on UDP. Since UDP is a much more light-weight protocol than TCP (e.g., UDP
provides no congestion control or error recovery), it is becoming increasingly
prevalent in embedded and resource-constrained computing domains [5,76]. For
example, UPnP [76] supports web service invocations on top of HTTP-UDP. Previous
research [8,14,82,83] has shown that the energy consumption of wireless
communication is directly proportional to the size of transmitted and received data.
Based on this, we quantify the communication energy consumption due to the j
th
invocation of component c
1
’s interface I
i
on host H
1
by component c
2
on host H
2
as
follows:
Eq. 5-4
Parameters tEvtSize and rEvtSize are the sizes (e.g., KB) of transmitted and received
messages on host H
1
during the j
th
invocation of I
i
. The remaining parameters are
host-specific. tEC
H1
and rEC
H1
are the energy costs (Joule/byte) on host H
1
while it
transmits and receives a unit of data, respectively. tS
H1
and rS
H1
represent constant
energy overheads associated with device state changes and channel acquisition [8].
( ) ( )
1 2 1 1 1 2 1 1
, ,
( , )
i c c H H c c H H
iCommEC I j tEvtSize tEC tS rEvtSize rEC rS = × + + × +
85
In Equation 5-4, the energy values of tEC, rEC, tS, and rS are constant and platform-
specific.
2
The system parameters that need to be monitored on each host are only the
sizes of messages exchanged (tEvtSize and rEvtSize, which include the overhead of
network protocol headers). Note that any transmission or receipt failures between the
sender and receiver hosts do not affect our estimates: UDP does not do any processing
to recover from such failures, while our framework uses the actual amount of data
transmitted and received in calculating the communication energy estimates.
5.2.3 Infrastructure Energy Cost
Once the computational and communication costs of a component have been
calculated based on its interfaces, its overall energy consumption is determined as
follows:
Eq. 5-5
However, in addition to the computational and communication energy costs, there are
additional energy costs for executing a Java component incurred by JVM’s garbage
collection and implicit OS routines. During garbage collection, all threads except the
garbage collection (GC) thread within the JVM process are suspended temporarily,
and the GC thread takes over the execution control. We suggest the following three
steps for estimating the energy consumption resulting from garbage collection: (1)
Determine the average energy consumption rate gEC of the GC thread (Joule/
2. We will elaborate on how these parameters are determined for an actual host in Chapter 6.
( ) ( ) ( ) overallEC c cCompEC c cCommEC c = +
86
second); (2) Monitor the total time tGC spent by the GC thread (second); and (3)
Multiply tGC by gEC to get the energy consumption of the GC thread. In Section 5.4
we describe in detail our approach for accurately monitoring the GC thread’s
execution time and measuring its average energy consumption rate.
Since a JVM runs as a separate user-level process in an OS, it is necessary to consider
the energy overhead of OS routine calls for facilitating and managing the execution of
JVM processes. There are two types of OS routines:
1. explicit OS routines (i.e., system calls), which are initiated by user-level applica-
tions (e.g., accessing files, or displaying text and images on the screen); and
2. implicit OS routines, which are initiated internally by the OS (e.g., context
switching, paging, and process scheduling).
In Java, applications initiate explicit OS routine calls via JVM’s native methods.
Therefore, Equation 5-2 already accounts for the energy consumption due to the
invocation of explicit OS routines. However, we have not accounted for the energy
overhead of executing implicit OS routines. Previous research has shown that process
scheduling, context switching, and paging are the main consumers of energy due to
implicit OS routine calls [37,71]. By considering these additional energy costs, we
can estimate the overall infrastructure energy overhead of a JVM process p as
follows:
Eq. 5-6 ( ) ( ) ( ) ( )
( )
p p p p
ifEC p tG C gEC csNum csEC pfNum pfE C prNum prEC = × + × + × + ×
87
Recall that gEC is the average energy consumption rate of the GC thread, while tGC
p
is the time that the GC thread is active during the execution of process p. csNum
p
,
pfNum
p
, and prNum
p
are, respectively, the numbers of context switches, page faults,
and page reclaims that have occurred during the execution of process p. csEC, pfEC,
and prEC are, respectively, the energy consumption of processing a context switch, a
page fault, and a page reclaim. We should note that csEC includes the energy
consumption of process scheduling as well as a context switch. This is due to the fact
that in most embedded OSs a context switch is always preceded by process
scheduling [71].
Since there is a singleton GC thread per JVM process, and implicit OS routines
operate at the granularity of processes, we estimate the infrastructure energy overhead
of a distributed software system in terms of its JVM processes. In turn, this helps us to
estimate a distributed system’s energy consumption with higher accuracy.
Unless two platforms have the same hardware configurations, JVMs, and OSs, the
energy values of gEC, csEC, pfEC, and prEC on one platform may not be the same as
those on another platform. We will describe how these values can be obtained for an
actual host in Chapter 6.
88
Once we have estimated the energy consumption of all the components, as well as the
infrastructure energy overhead, we can estimate the system’s overall energy
consumption as follows:
Eq. 5-7
where cNum and pNum are, respectively, the numbers of components and JVM
processes in the distributed software system.
5.2.4 Assumptions
In formulating the framework introduced in this chapter, we have made several
assumptions. Firstly, we assume that all of the host-specific energy values (e.g.,
energy consumption of each bytecode type, native method, and monitor operation)
used in our framework are known to the system engineer. The engineer can use
various ways to determine these energy values on a given host. In Chapter 6 we
discuss the approach we have taken in this dissertation.
Secondly, we assume that interpreter-based JVMs such as Sun Microsystems’ KVM
[31] and JamVM [21] are used on the hardware hosts. These JVMs have been
developed for resource-constrained platforms, and require much less memory than
“just-in-time” (JIT) compilation-based JVMs. If a JIT-based JVM is used, the energy
cost for translating a bytecode into native code “on the fly” would need to be added
into Equation 5-2 since the JIT compilation itself happens while a Java application is
1 1
( ) ( )
pNum cNum
i j
i j
systemEC overallEC c ifEC p
= =
= +
∑ ∑
89
being executed. We plan to investigate how our framework can be extended to JIT-
based JVMs as part of the future work.
Furthermore, we assume that the systems to which our framework is applicable will
be implemented in “core” Java. In other words, apart from the JVM, we currently do
not take into account the effects on energy consumption of any other middleware
platform. While this does not prevent our framework from being applied on a very
large number of existing Java applications, clearly in the future we will have to
extend this work to include other middleware platforms. For example, if a
middleware platform selected for our style energy consumption framework
(presented in Chapter 4) is purely implemented in Java and provides various facilities
(e.g., service discovery, fault tolerance, priority-based scheduling, etc.) at the level of
middleware-level components, we can simply use our framework presented in this
chapter for estimating the energy overhead resulting from those middleware-level
components. Otherwise, we need to extend our framework for estimating the energy
cost of the above middleware facilities in a different way.
We assume that the target network environment is a (W)LAN that consists of
dedicated routers (e.g., wireless access points) and stationary or mobile hosts. This is
representative of a majority of systems that rely on wireless connectivity and battery
power today. In the case of mobile hosts, we assume that each host associates itself
with an access point within its direct communication range and communicates with
90
other hosts via dedicated access points. In this setting, there could be a hand-off
overhead when mobile hosts move and change their associated access points.
However, it is not the software system that causes this type of energy overhead, but
rather the movement of the host (or user). Therefore, we currently do not consider
these types of overhead in our framework.
Note that in order to expand this work to a wireless ad-hoc network environment, we
also need to consider the energy overhead of routing event messages by each host.
This type of energy overhead can be accounted for by extending the infrastructure
aspect of our framework (recall Section 5.2.3). We plan to investigate this issue as
part of our future work.
The final assumption deals with our framework’s predictive power. Distributed,
mobile, embedded, and pervasive Java-based software systems, at which this work is
targeted, comprise a very large and heterogeneous class of systems deployed on many
different hardware, network, and software configurations with innumerable
performance and usage profiles. This is why it is very challenging for a framework
such as ours to be evaluated exhaustively for each, or even most, of the possible
scenarios in which it may actually be used. Even though we have tried to account for
many “boundary conditions” in our evaluation (see Chapter 6), we acknowledge that
our framework may actually exhibit different results from those reported in this
dissertation in situations in which the system is under attack by malicious intruders;
91
the network is shared with, or controlled by, other systems; the network is overloaded;
a given device, or set of devices, is (near) failing or overloaded to the point where the
infrastructure overhead dominates the other energy cost factors; and so on. In this
dissertation, we are necessarily assuming that the system’s operating conditions will
be within some expected, though broad, range: without a basic capability to estimate
the system’s energy usage in such “normal” cases, we cannot hope to be able to do so
for abnormal cases. Moreover, we postulate that, in a system under attack or one that
is experiencing serious performance problems, accurate energy consumption
estimates may not be the system stakeholders’ principal concern anyway.
5.3 Energy Consumption Estimation
In this section, we discuss how our energy consumption framework can be used for
estimating a distributed software system’s energy consumption at the level of its
components. Figure 5-3 shows the envisioned high-level process followed by a
system engineer for estimating a distributed system’s energy consumption using our
framework. As indicated in the figure, the framework can be applied both at system
construction-time and at runtime.
During the construction-time, the engineer characterizes the computational (described
in Section 5.2.1) and communication (Section 5.2.2) energy costs of each component
on its candidate host(s), and then estimates the infrastructure energy overhead
(Section 5.2.3) incurred by the initial deployment. The distributed system’s overall
92
energy consumption can then be calculated approximately based on these energy
estimates. During the runtime, the engineer refines the construction-time estimates of
each component’s energy consumption based on the actual inputs to each interface
and the actual size of data exchanged over the network. In a similar way, the
construction-time estimates of the infrastructure energy overhead can be improved
based on the actual GC thread execution time and the number of implicit OS routines
executed. The system’s overall energy consumption can be then estimated more
precisely based on these refined energy estimates. Each dotted line in Figure 5-3
indicates the refinement step at runtime for the corresponding energy estimation step
Figure 5-3: Energy consumption estimation steps at system construction-time and at runtime.
Characterize the
computational energy cost of
each interface on each
candidate host
Component 1 Component n Component 2 ...
Estimate the
communication energy cost
of each interface on each
candidate host
...
Estimate the
infrastructure energy cost on
the determined deployment
architecture
Determine the initial
deployment based on the
component-level energy
estimates
Estimate the overall
energy consumption of the
distributed system
System Construction-time
Energy Estimation
Based on the computational energy
behavior of each interface, do the one
of the following things for estimating its
computational energy cost:
i) use the construction-time estimates
as its energy cost
ii) refine the construction-time estimates
based on the actual inputs to the
interface
Based on the actual size of data
exchanged over the network, refine the
communication cost of each interface
estimated at construction-time
Improve the construction-time estimates
of infrastructure energy overhead by
monitoring the actual GC thread
execution time and the number of
implicit OS routines executed
Refine the construction-time energy
estimates of the distributed system
Runtime
Energy Estimation
93
at system construction-time. The estimation steps taken by the system engineer at
construction-time and at runtime will be explained in more detail in the remainder of
this section.
5.3.1 System Construction-Time Estimation
As indicated in Figure 5-3, in order to estimate a distributed system’s energy
consumption during construction-time we first need to characterize the computational
energy consumption of each component on its candidate hosts. To this end, identify
three different types of component interfaces:
I. An interface (e.g., a date component’s setCurrentTime) that requires the
same amount of computation regardless of its input parameters.
II. An interface (e.g., a data compression component’s compress) whose input size
is proportional to the amount of computation required.
III. An interface (e.g., DBMS engine’s query) whose input parameters have no
direct relationship to the amount of computation required.
For a type I interface, we need to profile the number of bytecodes, native methods,
and monitor operations only once for an arbitrary input. We can then calculate its
energy consumption from Equation 5-2.
For interfaces of type II, we first generate a set of random inputs, profile the number
of bytecodes, native methods, and monitor operations for each input, and then
calculate its energy consumption from Equation 5-2. However, the set of generated
94
inputs does not show the complete energy behavior of a type II interface. To
characterize the energy behavior of a type II interface for any arbitrary input, we
employ multiple regression [1]. Multiple regression is a method of estimating the
expected value of an output variable given the values of a set of related input
variables, and has been widely used in a data analysis field. For example, suppose that
there are sample sets of data showing the relationship between (1) the size of a house
(in square feet), the average income in the respective neighborhood according to
census data, and a subjective rating of appeal of the house, and (2) the price for which
a house is sold. By applying multiple regression to these data sets, we can then get an
equation that can estimate the price of a given house if the house’s size, the average
income in the neighborhood, and the house’s subjective rating are available. In our
case, by running multiple regression on a sample set of input variables’ values
generated for a type II interface and their corresponding energy costs calculated from
Equation 5-2, it is possible to construct an equation that estimates the relationship
between the input variables and their corresponding energy cost. In Chapter 6, we will
show an example of applying multiple regression to a component.
Interfaces of type III present a challenge because there is no direct relationship
between an interface’s input parameters and the amount of computation required, yet
a lot of interface implementations fall in this category (e.g., many Java methods
containing loops and branches). To characterize the energy behavior of type III
interfaces with a set of finite execution paths, we use symbolic execution [30], a well
95
known program analysis technique that allows using symbolic values for input
parameters to explore program execution paths. We leverage previous research
[28,29,78], which has suggested a generalized symbolic execution approach for
generating test inputs covering all the feasible execution paths, and use these
generated inputs for invoking a type III interface. We then profile the number of
bytecodes, native methods, and monitor operations for each input, estimate its energy
consumption from Equation 5-2, and finally calculate the interface’s average energy
consumption by dividing the total energy consumption by the number of generated
inputs.
The above approach works only for interfaces with finite execution paths, and is
infeasible for many interfaces whose implementations have infinite execution paths,
such as a DBMS engine. We use an approximation for such interfaces: we invoke the
interface with a set of inputs (either selected randomly or by leveraging system
testing information), calculate the energy consumption of the interface for each input
via Equation 5-2, and finally calculate the average energy consumption of the
interface by dividing the total consumption by the number of random inputs. This
approach will clearly not always give a representative estimate of the interface’s
actual energy consumption: if the chosen inputs result in execution paths that are
shorter (or longer) than the actual paths executed at runtime, the interface’s energy
consumption will be underestimated (or overestimated). Closer approximations can
be obtained if an interface’s expected runtime context is known (e.g., expected inputs,
96
their sizes, invocation frequency, and so on). As we will detail in Section 5.3.2, we
can also refine our construction-time energy estimates for type III interfaces by
monitoring the actual amount of computation performed at runtime.
The above classification of a component’s interfaces is based on their normal
execution paths. If an interface’s implementation has any exception handling routines,
they must be treated separately in calculating the interface’s energy cost. For
estimating the energy cost due to processing an exception, we target the exception by
generating inputs that raise it. We then profile the number of bytecodes, native
methods and monitor operations executed as a result of those inputs, and again
estimate the energy consumption from Equation 5-2. If our estimates of the frequency
with which the exception code will be executed prove to be incorrect, they can be
adjusted at runtime as detailed in Section 5.3.2.
For the communication energy consumption of each interface, based on domain
knowledge, types of input parameters and return values, and the target hardware
environment, at construction-time we predict the average size of messages exchanged
due to an interface’s invocation. Using this data we can calculate approximately the
communication energy consumption of interface invocation via Equation 5-4. Finally,
based on these analyses for computational and communication energy costs of each
interface, we can estimate the overall energy consumption of a component on its
candidate host(s) using Equations 5-1, 5-3, and 5-5.
97
Before estimating the entire distributed software system’s energy consumption, we
also need to determine the infrastructure’s energy overhead. This overhead depends
on the deployment of the software (e.g., the number of components executing
simultaneously on each host). Unless the deployment of the system’s components on
its hosts is fixed a priori, the component-level energy estimates can help an engineer
determine an initial deployment that satisfies the system’s energy requirements (e.g.,
to avoid overloading an energy-constrained device). Once an initial deployment is
determined, from Equation 5-6 we can estimate the infrastructure’s energy
consumption. We do so by executing all the components on their target hosts
simultaneously, with the same sets of inputs that were used in characterizing the
energy consumption of each individual component. Finally, we determine the
distributed system’s overall energy consumption via Equation 5-7.
5.3.2 Runtime Estimation
Many systems for which energy consumption is a significant concern are long-lived,
dynamically adaptable, and mobile. An effective energy cost framework for such
systems should account for variations in the energy consumption due to changes in
the runtime environment, or due to the system’s adaptations. In this section, we
discuss our approach to refining our construction-time energy estimates of a
component after its initial deployment.
98
The initial deployment of a software system onto the target hosts may be based on
energy cost estimates that are made during system construction-time. However, many
aspects of the system, such as the frequency with which interfaces of a component are
actually invoked and the amount of data actually exchanged across the network, may
have not been accurately estimated. The construction-time estimates are based on a
system engineer’s guesses or domain knowledge. For a large class of systems, such as
the sensor-based distributed application that was discussed in Chapter 1 and shown in
Figure 1-1, most of the runtime properties can be predicted fairly accurately at
construction-time: the sizes of event messages exchanged between the F AR and F AA
components can be estimated based on the application’s requirements; likewise,
invocation frequency of F AA’s interface that processes events from F AR is actually
equal to the frequency of signals from a fire-alarm sensor, which can be set prior to
the system’s initial deployment. On the other hand, in many distributed systems, such
as highly user-driven systems (e.g., see Section 6.2.5 in Chapter 6), construction-time
estimates may differ from the system’s actual use, and thus from the system’s actual
energy consumption. In such situations, more accurate estimates are only possible at
runtime as discussed below.
The amount of computation associated with a type I interface is constant regardless of
its input parameters. If the sizes of the inputs to a type II interface significantly differ
from those predicted at construction-time, new energy estimates can be calculated
very efficiently and accurately from its energy equation generated by multiple
99
regression. Recall from Section 5.3.1 that for interfaces of type III our construction-
time estimates may be inaccurate due to the fact that we may not be able to predict the
frequency of invocation or the execution paths taken (e.g., the exception handling
code). Therefore, to refine a type III interfaces’ construction-time estimates, we need
to monitor the actual amount of computation at runtime (i.e., number of bytecodes,
native methods, and monitor operations). In Section 5.4 we will present an efficient
mechanism for monitoring these parameters.
For the communication cost of each component, by monitoring the sizes of messages
exchanged over the network links, we can determine their effects on each interface’s
communication cost, and thus update a component’s overall energy cost
automatically.
Finally, the fact that the frequency at which interfaces are invoked may vary
significantly from what was predicted at construction-time, and the fact that the
system may be adapted at runtime, may result in inaccurate construction-time
infrastructure energy estimates. Therefore, the GC thread execution time and the
number of implicit OS routines (i.e., context switching, page faults, and page
reclaims) invoked at runtime must also be monitored by using the manner described
in Section 5.4. We discuss the overhead of this monitoring in Chapter 6. Based on the
refined estimates of each interface’s computational and communication costs, and of
the infrastructure’s energy overhead, we will be able to improve (possibly
100
automatically) our construction-time energy estimates of distributed systems at
runtime.
5.4 Monitoring
For supporting component-level energy consumption estimates during runtime, we
need to monitor the numbers of bytecodes, native methods, monitor operations, and
implicit OS routines, as well as the GC thread execution time. For this, we have
instrumented Kaffe 1.1.5 JVM [25], a target JVM platform for our framework, to pro-
vide the required monitoring facilities. However, since the monitoring activity itself
also consumes energy, we have to ensure that our monitoring mechanism is as light-
weight as possible. To this end, we have modified Kaffe’s source code by adding
1. an integer array of size 256 for counting the number of times each bytecode type
is executed;
2. integer counters for recording the number of times the different native methods
are invoked; and
3. an integer counter for recording the number of monitor operations executed.
As mentioned in Section 5.3.2, this type of runtime monitoring is only used for type
III interfaces.
In addition, we have added a global timer to Kaffe’s GC module to keep track of its
total execution time. This timer has a small overhead equivalent to two system calls
(for getting the times at the beginning and at the end of the GC thread’s execution).
101
For the number of implicit OS routines (i.e., context switching, page faults, page
reclaims), we simply used the facilities provided by the OS. Since both Linux and
Windows by default store the number of implicit OS routines executed in each pro-
cess’s Process Control Block, we do not introduce any additional overhead. We will
discuss the overhead of this monitoring facility in Chapter 6.
5.5 Practical Applications of the Estimation Framework
In this section we discuss several concrete applications for the framework. For each
case, we will highlight the support provided by our framework and outline our
strategy for realizing the approach.
5.5.1 Determining the Initial Deployment Architecture
The deployment architecture (i.e., the allocation of the system’s software components
to its hardware hosts) may have a significant impact on the overall energy
consumption of a distributed system. For example, we can reduce the communication
energy consumption by collocating frequently communicating components on the
same host. As shown in Section 5.3.1, at construction-time we can estimate the
system’s overall energy consumption for each possible deployment architecture by
using our estimation framework. However, determining the most energy-efficient
deployment architecture is an exponentially complex problem: in the most general
case its complexity is h
n
, where h is the number of target hosts and n is the number of
software components.
102
For addressing the above issue, a recent related project has suggested an efficient
approach for determining a deployment architecture of a distributed system that
satisfies a number of desirable qualities, including energy efficiency [41]. This
estimation framework was used to estimate the energy consumption of software
components on different types of devices. These estimates were then fed into various
optimization algorithms presented in [41] for finding an appropriate initial
deployment architecture for the system. This approach would be particularly useful in
domains (such as distributed real-time embedded systems), where the system’s
expected runtime context is known or can be predicted accurately at construction-
time.
5.5.2 Off-Loading Components
A typical distributed software system provides a number of services. Each service is
realized via a sequence of interactions among a subset of the software components
that make up the system. Usually, a particular subset of the services is especially
important to the system’s stakeholders. We refer to these services as mission-critical.
One approach to reducing the energy consumption of a distributed system such that
its most critical functionality remains intact is to off-load “unimportant” components
at runtime. We can define “unimportant” software components as those components
that are not essential to the existence of mission-critical services. By off-loading such
components, we free up scarce energy resources for the more critical software
components. Given that our goal is to increase the lifetime of mission-critical
103
services, we need to determine the lifetime of each service based on the software
components that participate in its provision. The lifetime of a service is equal to the
lifetime of its shortest-lived constituent component. In turn, a software component’s
lifetime depends on the available energy on the host on which it resides and the
energy consumption rate of all the components that execute on that host. Every time a
component is off-loaded, the lifetimes of other components on the given host (and
consequently the services that depend on those components) are extended.
Since our framework can estimate a distributed system’s energy consumption at the
level of its components, we can correctly determine the impact of off-loading a
component on the lifetime of other components at runtime. However, we need to
devise appropriate mechanisms for triggering the off-loading. We also need to
investigate issues such as what effects (frequent) component off-loading may have on
system users. As part of our future work, we intend to implement an efficient
component off-loading mechanism that will leverage the energy estimates from our
framework. In doing so we will rely on our Java-based middleware platform, Prism-
MW [39], which supports architecture-based distributed software development and
(re)deployment.
5.5.3 Modifying Components
Another approach that has been employed in energy-aware systems is dynamic
adaptation of software components’ interfaces. Researchers have shown that mobile
104
applications such as video players and map viewers can dynamically modify their
interfaces to conserve energy [11,13]. They typically define several quality levels for
each application (e.g., different filtering and cropping levels for a map viewer), and
then provide facilities to dynamically balance energy conservation and application
quality. A major shortcoming of these approaches is their inability to estimate the
energy consumption of applications when they are running simultaneously.
Our energy consumption framework can be used for providing a more efficient and
generally applicable solution. In these types of scenarios, the variations in the quality
levels of a component’s interface can be expressed in terms of the sizes of input
parameters used to invoke the interface and of the data that is communicated back.
Therefore, our framework can be directly leveraged to estimate the energy
consumption of each software component due to the changes in the interface-level
parameters both during system construction-time and during runtime. Similar to
component off-loading, we would still need to devise a way of triggering the dynamic
adaptation of component’s interfaces and determining their appropriate quality levels
and frequencies. We plan to investigate the relevant issues in the context of our
Prism-MW middleware platform [39].
5.5.4 Modifying the Deployment Architecture
After a system is deployed, some hosts may run out of battery power significantly
faster than others. This typically occurs when good estimates of the system’s energy
105
consumption are not available at construction-time. Even when good initial estimates
are available, some hosts may run out of battery faster than others due to unplanned
load increases. While the preceding two techniques can be used to reduce the energy
consumption on the overloaded hosts, these techniques would (significantly) reduce
the functionality provided by the software system. A preferable alternative may be to
redeploy the software components onto hosts with abundant energy resources at
runtime. To determine which components should be redeployed, it is necessary to
identify a set of components that are currently consuming a lot of energy on hosts
with scarce resources. Our framework can be used directly in support of this task.
A recent related project has resulted in several algorithms for improving a distributed
system’s quality-of-service (e.g., availability, latency, energy efficiency) via runtime
redeployment of its software components [41,47]. In the process, an integrated
middleware solution has been developed, which allows system parameters to be
monitored at runtime and provides autonomic agents that leverage the algorithms to
improve the system’s deployment architecture [39]. As part of our future work, we
plan to build on this foundation and our estimation framework to provide an
integrated solution for lengthening the lifetime of software systems in energy-
constrained environments.
106
CHAPTER 6: Evaluation
We have evaluated our solution on a large number of distributed application scenarios
with respect to the objectives and hypotheses that have guided this dissertation
research. First, we present and discuss the evaluation results for the framework that
estimates the energy consumption induced by a distributed system’s architectural
styles, in terms of precision and accuracy. We then show the evaluation results for the
framework that estimates the energy consumption of a component-based distributed
system implemented in Java both during system construction-time and during runt-
ime.
6.1 Framework for a Distributed System’s Architectural Styles
This section presents the results of evaluating our style-induced energy estimation
framework on a large number of application scenarios. First, we provide an overview
of the experiment setup, and then show how we can obtain the values of platform-spe-
cific energy cost parameters required by our framework. Next, in order to evaluate the
precision and accuracy of our framework’s estimates, we measured the actual energy
costs induced by architectural styles for our application scenarios. We then compared
these values to the energy consumption predictions from our framework.
107
6.1.1 Experimental Setup
We selected Prism-MW as our implementation platform for two reasons: (1) Prism-
MW is a light-weight middleware intended for embedded and resource constrained
systems, where energy efficiency is of utmost importance; and (2) Prism-MW pro-
vides explicit support for multiple architectural styles, giving us a common platform
to evaluate the framework’s accuracy in identifying the energy trade-offs between dif-
ferent styles. We chose a version of Prism-MW that runs on top of the JamVM 1.4.5
[21], which is a lightweight JVM. As our target hardware platform, we used a Com-
paq iPAQ 3800 device running embedded Linux, with a 206MHz Intel StrongARM
processor, 64MB memory, and 11Mbps 802.11b compatible wireless PCMCIA card.
In order to measure (1) platform-specific energy cost parameters and (2) the actual
energy consumption induced by a distributed system’s architectural styles, we used
the measurement setup shown in Figure 6-1. A Compaq iPAQ device was connected
to an external 5V DC power supply. We also used an HP 3458-a digital multimeter.
For measuring the current drawn by the iPAQ, we connected it to the multimeter,
Figure 6-1: Experimental setup.
Java
Components
PDA
Power Supply
Digital
Multimeter
Data Collection
Computer Java
Components
PDA
Power Supply
Digital
Multimeter
Data Collection
Computer
108
which was configured to take current samples at a high frequency. A data collection
computer controlled the multimeter and read the current samples from it.
6.1.2 Measurement
For each style, to measure the values of platform-specific energy cost parameters
used by our framework, we have created a simple benchmark application with that
style on top of Prism-MW and executed the application on the iPAQ devices. For
example, Figure 6-2 shows a benchmark application with the C2 style used for profil-
ing the platform-specific energy cost parameters for the C2 style. In this application,
both Comp B and Comp C on Host 2 send a request to Comp A on Host 1, which then
sends a notification event to them asynchronously through a C2 connector.
Figure 6-2: C2 architecture in Prism-MW.
H o s t 1
H o s t 2
C 2 c o n n e c to r
C o m p A
C o m p B C o m p C
C 2 c o n n e c to r
L e g e n d :
C o m p o n e n t/ C o n n e c to r
R e q u e s t P o rt
R e p ly P o rt
D is trib u tio n R e q u e s t
P o rt
D is trib u tio n
R e p ly P o rt
109
Since we were able to map the platform-specific energy cost parameters to the inter-
faces provided by a C2 component and a C2 connector as discussed in Section 4.3.2,
we only needed to measure the energy consumption due to invoking those interfaces
using the measurement setup in Figure 6-1. For instance, we can measure the energy
cost of invoking the send interface of a C2 component (e.g., Comp B in Figure 6-2)
for obtaining the value of the platform-specific energy cost E
toConn
on the component.
Similarly, we can simply measure the energy consumption of other interfaces (e.g.,
handle interface of a C2 connector, send/receive interfaces of a C2 connector’s distri-
bution ports) for profiling their corresponding platform-specific energy cost parame-
ters.
6.1.3 Evaluation Results
In this section, we present the evaluation results of our style-induced energy estima-
tion framework for various distributed application scenarios.
6.1.3.1 Sensor Applications
As the first scenario, consider the distributed sensor application shown in Figure 1-1
of Chapter 1, where Hosts 2 and 3 have much lower battery capacities than Host 1. In
addition to the client-server and publish-subscribe styles shown in Figure 1-1, we
have modeled the application in the C2 style. In the C2 architecture, if the FireAlarm-
Analyzer (IntrusionAlarmAnalyzer) component on Host 1 concludes that there is a
fire (intrusion), it sends a sensor-activation message to the local C2 connector, which
110
then broadcasts the message to remote C2 connectors on both Hosts 2 and 3. This
indicates that each sensor-activation message requires two transmissions on Host 1
although the message’s actual destination is either the FireAlarmReceiver or Intru-
sionAlarmReceiver component, but not both. Therefore, compared with the client-
server and C2 architectures, the publish-subscribe architecture requires fewer mes-
sages to be exchanged over the network because of the reasons discussed in the above
and in Chapter 1. However, the publish-subscribe architecture incurs the additional
overhead of managing lists of publishers and subscribers and retrieving a set of sub-
scribers for each published event.
Once the above three architectural models were parameterized with platform-specific
energy costs, we evaluated our framework by varying the frequencies and sizes of
alarm events stochastically. The framework suggested that utilizing the publish-sub-
scribe style results in significant energy savings, and that C2 is more energy-efficient
than client-server.
In order to determine the accuracy of the estimates made by the framework, we used
the same frequencies and sizes of alarm events as those simulated in our framework,
measured the energy consumption on each host (i.e., the iPAQ device from Figure 6-
1) induced by each style by using the multimeter, and finally calculated the overall
energy consumption induced by each style by summing up the three hosts’ energy
costs. As shown in Figure 6-3, the energy consumption estimates from our framework
111
fell within 7% of the measured energy costs for all three styles. Moreover, as our
framework predicted, the publish-subscribe style was determined to be much more
energy-efficient for this scenario because the energy cost incurred by exchanging
more data remotely in both the client-server and the C2 styles exceeds the energy
overhead due to processing subscriptions and retrieving a set of subscribers for each
event in the publish-subscribe style.
For the second scenario, consider the case shown in Figure 6-4, where all the hosts
have the same battery capacities. In this case, it is not desirable to allocate all the
energy-intensive Analyzer and Logger components to a single host because the host
would deplete its battery power quickly, which can prevent the distributed application
from providing its key services. Figure 6-4 shows one possible allocation, which dis-
tributes the Analyzer and Logger components evenly to the three hosts. As shown in
Figure 6-3: Framework’s accuracy for the distributed application in Figure 1-1.
The values are in mJ.
86933
87927
118451
121198
142255
145654
2.3 5 3.3 1.3 0.7
Frequency
(times/sec)
Style
318870 218311 86126 42560
Client-Server
Measured
304831 203220 81288 40644
Client-Server
Estimated
186285 124190 49676 24838
Pub-Sub
Estimated
187596 125384 49850 25174
Pub-Sub
Measured
253823 169215 67686 33843
C2
Estimated
259021 170953 67231 33601
C2
Measured
86933
87927
118451
121198
142255
145654
2.3 5 3.3 1.3 0.7
Frequency
(times/sec)
Style
318870 218311 86126 42560
Client-Server
Measured
304831 203220 81288 40644
Client-Server
Estimated
186285 124190 49676 24838
Pub-Sub
Estimated
187596 125384 49850 25174
Pub-Sub
Measured
253823 169215 67686 33843
C2
Estimated
259021 170953 67231 33601
C2
Measured
112
the figure, we have modeled the application with the peer-to-peer and C2 styles. We
also designed the application with the publish-subscribe style.
In the C2 architecture, each fire (intrusion) alarm requires the remote transmission of
two requests on Host 1 because its C2 connector broadcasts the alarm to the remote
C2 connectors on both Hosts 2 and 3 although the alarm is actually processed by
either the FireAlarmAnalyzer or IntrusionAlarmAnalyzer component, but not both.
Therefore, compared with the peer-to-peer architecture, the C2 architecture requires
more data to be exchanged over the network. On the other hand, both the peer-to-peer
and the publish-subscribe architectures require the same numbers of alarm events and
sensor-activation messages exchanged over the network because (1) the two destina-
tion components of an alarm event are running on two different hosts (i.e., Hosts 1
and 2, or Hosts 1 and 3); and (2) a sensor activation message has only one destination
component (i.e., FireAlarmReceiver or IntrusionAlarmReceiver). However, the pub-
Figure 6-4: A distributed sensor application designed in peer-to-peer (left) and c2 (right) styles.
Alarm
Logger
Host 1
Host 2 Host 3
Peer-to-Peer
Connector
Fire Alarm
Receiver
Intrusion Alarm
Analyzer
Fire Alarm
Analyzer
Host 1
Host 2 Host 3
Fire Alarm
Receiver
Intrusion Alarm
Receiver
C2 Connector
Fire Alarm
Analyzer
C2 Connector
Intrusion Alarm
Analyzer
C2 Connector
Alarm
Logger
Intrusion Alarm
Receiver
Peer-to-Peer
Connector
Peer-to-Peer
Connector
Peer-to-Peer
Connector
Peer-to-Peer
Connector
113
lish-subscribe architecture causes the additional overhead resulted from managing
lists of publishers and subscribers and performing lookup tasks.
By using our framework, we have performed the energy consumption analysis for the
above three styles. As shown in Figure 6-5, both our framework’s analyses and the
actual comparison results indicate that the peer-to-peer architecture is more energy-
efficient than the architectures in the other two styles because of the reasons discussed
above, and the energy consumption estimates from the framework were within 6% of
the actually measured energy costs for all three styles regardless of the frequencies of
alarm messages.
As the last sensor application scenario, we have added LocalSensorInfoMgmt and
GlobalSensorInfoMgmt components to the distributed application in Figure 1-1 of
Figure 6-5: Framework’s accuracy for the distributed application in Figure 6-4.
The values are in mJ.
88859
92437
142260
149348
86908
88781
2.3 5 3.3 1.3 0.7
Frequency
(times/sec)
Style
191571 129815 51540 24950
Peer-to-Peer
Measured
186232 124155 49661 24831
Peer-to-Peer
Estimated
188219 126119 51599 26759
Pub-Sub
Estimated
194424 133143 53574 27048
Pub-Sub
Measured
304844 203230 81292 40646
C2
Estimated
318908 212451 85069 42888
C2
Measured
88859
92437
142260
149348
86908
88781
2.3 5 3.3 1.3 0.7
Frequency
(times/sec)
Style
191571 129815 51540 24950
Peer-to-Peer
Measured
186232 124155 49661 24831
Peer-to-Peer
Estimated
188219 126119 51599 26759
Pub-Sub
Estimated
194424 133143 53574 27048
Pub-Sub
Measured
304844 203230 81292 40646
C2
Estimated
318908 212451 85069 42888
C2
Measured
114
Chapter 1, as shown in Figure 6-6. The LocalSensorInfoMgmt component manages
the database (e.g., location, type, liveness, etc.) of all of its local sensors, and also
transfers the database’s content periodically to the GlobalSensorInfoMgmt component
that manages the global database of all the sensors. We have designed four variants of
the extended application with the publish-subscribe and hybrid (publish-subscribe +
client-server) styles, as shown in Figure 6-6, as well as the client-server and C2
styles.
In this application, compared with the publish-subscribe style, the client-server and
C2 styles still cause more data to be exchanged over the network because of the rea-
sons discussed in the first scenario. Both the publish-subscribe and the hybrid styles
require the same amount of data to be exchanged remotely as events from the
LocalSensorInfoMgmt components have only one destination component (i.e., Glo-
balSensorInfoMgmt). But, the hybrid style incurs less overhead caused by retrieving a
Figure 6-6: A distributed sensor application designed in publish-subscribe (left) and hybrid
(right) styles.
Fire
Alarm
Analyzer
Alarm
Logger
Fire
Alarm
Receiver
Host 1
Host 2
Intrusion
Alarm
Receiver
Host 3
Intrusion
Alarm
Analyzer
Pub-Sub
Connector
Pub-Sub
Connector
Publish-Subscribe
Connector
Global
SensorInfo
Mgmt
Local
SensorInfo
Mgmt
Local
SensorInfo
Mgmt
Fire
Alarm
Analyzer
Alarm
Logger
Fire
Alarm
Receiver
Host 1
Intrusion
Alarm
Receiver
Intrusion
Alarm
Analyzer
Pub-Sub
Connector
Pub-Sub
Connector
Global
SensorInfo
Mgmt
Local
SensorInfo
Mgmt
Local
SensorInfo
Mgmt
Client-Server
Connector
Client-Server
Connector
Host 2 Host 3
Client-Server
Connector
Publish-Subscribe
Connector
115
set of subscribers for each published event because events from the LocalSensorInfo-
Mgmt components are directly forwarded to the GlobalSensorInfoMgmt via their own
connectors.
Figure 6-7 shows both the energy consumption estimates from our framework and the
actual energy costs for the above four styles. The publish-subscribe style is still more
energy-efficient than the client-server and C2 styles because of the reasons discussed
in the first scenario. However, the hybrid style is slightly better than the publish-sub-
scribe style in terms of energy savings, resulting from the reduced lookup overhead.
The energy consumption estimates from the framework fell within 6% of the actual
energy costs for all four styles.
Figure 6-7: Framework’s accuracy for the distributed application in Figure 6-6.
The values are in mJ.
304614 204101 143794 83486 43281
Pub-Sub Estimated
312650 208135 147502 84377 43679
Hybrid
Measured
303428 202926 142625 82323 42122
Hybrid
Estimated
149554
172462
176921
196251
206321
2.3 5 3.3 1.3 0.7
Frequency
(times/sec)
Style
441354 295013 117958 58879
Client-Server
Measured
420539 280360 112144 56072
Client-Server
Estimated
316523 211337 85854 44845
Pub-Sub Measured
369562 246375 98550 49275
C2
Estimated
378241 251655 101083 50523
C2
Measured
304614 204101 143794 83486 43281
Pub-Sub Estimated
312650 208135 147502 84377 43679
Hybrid
Measured
303428 202926 142625 82323 42122
Hybrid
Estimated
149554
172462
176921
196251
206321
2.3 5 3.3 1.3 0.7
Frequency
(times/sec)
Style
441354 295013 117958 58879
Client-Server
Measured
420539 280360 112144 56072
Client-Server
Estimated
316523 211337 85854 44845
Pub-Sub Measured
369562 246375 98550 49275
C2
Estimated
378241 251655 101083 50523
C2
Measured
116
6.1.3.2 Rescue Applications
Figure 6-8 shows a distributed rescue application designed with the C2 and the client-
server styles, which runs on one headquarter and four commander hosts. In this appli-
cation, the ResourceMonitor component running on each commander host keeps track
of rescue resources, and transmits an event containing the updated resource informa-
tion periodically to all the components (i.e., ResourceDatabase, DeploymentAnalyzer,
and RescueStrategyAnalyzer) on the headquarters host. The ResourceDatabase then
updates its database containing the information about all the resources managed by
four commanders, while the DeploymentAnalyzer (RescueStrategyAnalyzer) pro-
cesses an event from the ResourceMonitor and generates an event containing the
resource-deployment (rescue-strategy) information, which is then received and pro-
cessed by all the components (i.e., ResourceMonitor, MapViewer, and Communica-
tor) on all the commander hosts. In addition to the C2 and the client-server styles, we
Figure 6-8: A distributed rescue application designed in the C2 (left) and the client-server
(right) styles.
Resource
M onitor
Headquarters
Com m ander 1 Com m ander 4
…
R esource
D atabase
D eploym ent
Analyzer
Rescue
Strategy
Analyzer
M ap
View er
Com m uni-
cator
R esource
M onitor
M ap
View er
Com m uni-
cator
C 2 C onnector C 2 C onnector
…
C 2 C onnector
Resource
M onitor
Headquarters
Com m ander 1 Com m ander 4
…
Rescue
Strategy
Analyzer
M ap
View er
C om m uni-
cator
R esource
M onitor
M ap
View er
C om m uni-
cator
R esource
D atabase
D eploym ent
Analyzer
…
C lient-Server
C onnector
Client-S erver
Connector
Client-S erver
Connector
Client-S erver
Connector
Client-Server
Connector
Client-Server
C onnector
Client-S erver
Connector
C lient-Server
C onnector
Client-S erver
Connector
117
designed this application with the publish-subscribe style by replacing a C2 connector
on each host with a pub-sub connector.
In the C2 (publish-subscribe) architecture, each message from the ResourceMonitor
on each commander host requires one remote transmission to the C2 (publish-sub-
scribe) connector on the headquarters host because all the destination components for
the message are running on the headquarters. Each response from the DeploymentAn-
alyzer or RescueStrategyAnalyzer requires one remote transmission to the C2 (pub-
lish-subscribe) connector on each commander host as each response’s destinations are
all the components running on all the commander hosts. Therefore, compared with
the C2 style, the publish-subscribe style exchanges the same amount of data both
remotely and locally, but incurs additional overhead caused by processing subscrip-
tions and retrieving a set of subscribers for each event. In the client-server style, as
point-to-point interactions between components are used, each message from the
ResourceMonitor incurs three separate remote transmissions to the headquarters host,
while each response from the DeploymentAnalyzer or RescueStrategyAnalyzer causes
three separate remote transmissions to each commander host. Consequently, the cli-
ent-server style requires more data to be exchanged remotely than the C2 or publish-
subscribe styles.
Figure 6-9 compares the energy consumption estimates from our framework with the
actual energy costs for the above three styles. As our framework predicted, the C2
118
style is the most energy-efficient, while the publish-subscribe style is more energy-
efficient than the client-server style because the energy overhead caused by exchang-
ing more data remotely in the client-server style exceeds the overhead due to process-
ing subscriptions and retrieving a set of subscribers for each event in the publish-
subscribe style. Moreover, the energy consumption estimates from our framework
were within 7% of the actual energy costs induced by the above three styles.
6.1.3.3 Mobile Employee Applications
Figure 6-10 shows a mobile employee application designed using the client-server
and the publish-subscribe styles, which runs on two servers and eight employee
devices. The CustomerClient component on each employee device sends a customer
information and a customer service request to the CustomerDatabase and the Custom-
Figure 6-9: Framework’s accuracy for the distributed application in Figure 6-8.
The values are in mJ.
2044692 1364060 955680 547299 275047
Pub-Sub
Estimated
6489745 4314282 3000134 1722146 853165
Client-Server
Measured
2857141
1017790
952482
1014381
2.8 6 4 1.6 0.8
Frequency
(times/sec)
Style
2169628 1442345 571502 288456
C2
Measured
2041036 1360690 544279 272138
C2
Estimated
6122445 4081630 1632652 816326
Client-Server
Estimated
2173517 1445915 574675 291541
Pub-Sub
Measured
2044692 1364060 955680 547299 275047
Pub-Sub
Estimated
6489745 4314282 3000134 1722146 853165
Client-Server
Measured
2857141
1017790
952482
1014381
2.8 6 4 1.6 0.8
Frequency
(times/sec)
Style
2169628 1442345 571502 288456
C2
Measured
2041036 1360690 544279 272138
C2
Estimated
6122445 4081630 1632652 816326
Client-Server
Estimated
2173517 1445915 574675 291541
Pub-Sub
Measured
119
erService components, respectively, which then process the request and send its
response to the CustomerClient. Similarly, the InventoryClient (BillingClient) sends
an inventory (billing) information request to the InventoryManager (BillingManager),
which then processes the request and replies to the InventoryClient (BillingClient). We
also designed this application with the C2 style by replacing a publish-subscribe con-
nector on each host with a C2 connector.
Since the number of destination components for every message type is one, the
amount of data exchanged locally and remotely is the same in both the client-server
and publish-subscribe styles. However, the publish-subscribe style incurs the addi-
tional overhead caused by processing subscriptions and retrieving a set of subscribers
for each event. On the other hand, the C2 architecture causes more data to be
exchanged locally and remotely than the client-server and the publish-subscribe styles
because the C2 connector on each employee (server) host broadcasts a request (reply)
Figure 6-10: A mobile employee application designed in client-server (left) and publish-
subscribe (right) styles.
Server 1
Em ployee 1
…
C ustom er
D atabase
Server 2
Inventory
M anager
Client-Server
C onnector
Client-Server
C onnector
C ustom er
C lient
Inventory
C lient
Billing
C lient
C ustom er
S ervice
B illing
M anager
Client-Server
C onnector
Client-Server
C onnector
C lient-S erver
C onnector
C lient-Server
C onnector
C lient-Server
C onnector
…
Em ployee 8
C ustom er
C lient
Inventory
C lient
Billing
C lient
C lient-Server
C onnector
C lient-Server
C onnector
C lient-Server
C onnector
Server 1
Em ployee 1
…
C ustom er
D atabase
Server 2
Inventory
M anager
C ustom er
C lient
Inventory
C lient
B illing
C lient
C ustom er
Service
Billing
M anager
Pub-Sub Connector Pub-Sub Connector
Pub-Sub Connector
…
Em ployee 8
C ustom er
C lient
Inventory
C lient
B illing
C lient
Pub-Sub Connector
120
message to all the server (employee) hosts regardless of the message’s actual destina-
tions.
As shown in Figure 6-11, the energy consumption estimates from our framework
were within 7% of the actually measured costs for all three styles. In addition, our
framework correctly ranked the styles with respect to their energy costs. In this appli-
cation, the client-server style is most energy-efficient, while the publish-subscribe
style is second most efficient because the energy overhead caused by exchanging
more data in the C2 style is much larger than the cost resulting from processing sub-
scriptions and retrieving a set of subscribers in publish-subscribe.
Figure 6-11: Framework’s accuracy for the distributed application in Figure 6-10.
The values are in mJ.
1080520
1150773
6178930
6580460
1065371
1134633
4.6 9.8 6.5 2.6 1.3
Frequency
(times/sec)
Style
2408409 1613378 642278 322644
Client-Server
Measured
2282942 1521961 608785 304392
Client-Server
Estimated
2298372 1537215 623826 319362
Pub-Sub
Estimated
2424684 1629557 658151 338535
Pub-Sub
Measured
13240563 8827042 3530815 1765408
C2
Estimated
13968543 9356758 3725119 1871315
C2
Measured
1080520
1150773
6178930
6580460
1065371
1134633
4.6 9.8 6.5 2.6 1.3
Frequency
(times/sec)
Style
2408409 1613378 642278 322644
Client-Server
Measured
2282942 1521961 608785 304392
Client-Server
Estimated
2298372 1537215 623826 319362
Pub-Sub
Estimated
2424684 1629557 658151 338535
Pub-Sub
Measured
13240563 8827042 3530815 1765408
C2
Estimated
13968543 9356758 3725119 1871315
C2
Measured
121
6.1.3.4 XML Stream Applications
Figure 6-12 depicts a distributed XML stream application designed in the pipe-and-
filter and C2 styles. The application runs on nine hosts, where one host pushes XML
data stream to the other eight hosts. In this application, the XML Data Source compo-
nent sends XML data to the HTML Viewer and WML Viewer components through the
XML-to-HTML and the XML-to-WML components, respectively. The XML-to-HTML
(XML-to-WML) component converts XML data stream to the HTML (WML) format.
The actual destinations of the converted data from the XML-to-HTML (XML-to-
WML) component are only the HTML Viewer (WML Viewer) components. Therefore,
the C2 architecture causes more data to be exchanged over the network than the pipe-
and-filter architecture because the C2 connector on Host 1 broadcasts HTML or
WML data to all the other hosts regardless of the types of their viewer components.
Figure 6-12: An XML data stream application designed in pipe-and-filter (left) and C2 (right)
styles.
Host 1
Host 2 Host 9
…
XML-to-HTML XML-to-WML
C2 Connector
HTML Viewer WML Viewer
Host 1
Host 2 Host 9
…
XML-to-HTML XML-to-WML
Pipe
HTML Viewer
XML Data Source
C2 Connector
C2 Connector C2 Connector
… …
Pipe
Pipe
WML Viewer
Pipe Pipe
XML Data Source
122
As shown in Figure 6-13, our framework was able to produce energy consumption
estimates that fell within 6% of the actual energy costs induced by the pipe-and-filter
and C2 styles. In addition, as our framework predicted, the pipe-and-filter style
proved to be more energy-efficient than the C2 style because of the above reasons.
6.2 Framework for Distributed Java-Based Systems
In this section we first describe our evaluation environment for our energy estimation
framework for distributed Java-based systems and then the tools on which we relied.
We also describe our strategy in selecting Java components for the evaluation, and
detail the energy measurement and monitoring approaches we have used. Finally, we
present the results of evaluating our framework in estimating the energy consumption
of distributed Java-based systems.
Figure 6-13: Framework’s accuracy for the distributed application in Figure 6-12.
The values are in mJ.
449397
471937
224704
235845
3.52 5.63 4.62 2.68 1.63
Avg. size
(KB)
Style
338860 287303 193432 144763
Pipe-Filter
Measured
322429 274704 186067 138341
Pipe-Filter
Estimated
644849 549398 372127 276676
C2
Estimated
677492 574438 387319 289435
C2
Measured
449397
471937
224704
235845
3.52 5.63 4.62 2.68 1.63
Avg. size
(KB)
Style
338860 287303 193432 144763
Pipe-Filter
Measured
322429 274704 186067 138341
Pipe-Filter
Estimated
644849 549398 372127 276676
C2
Estimated
677492 574438 387319 289435
C2
Measured
123
6.2.1 Experimental Setup
In order to evaluate the accuracy of our framework’s estimates, we need to know the
actual energy consumption of a software component or system. To this end, similar to
the setup shown in Figure 6-1, we used a digital multimeter, which measures the fac-
tors influencing the energy consumption of an iPAQ device: voltage and current.
Since the input voltage is fixed in our experiments, the energy consumption can be
measured based on the current variations going from the energy source to the device.
To measure the actual energy consumption of running software on an iPAQ device,
we first monitor the constant amount of current drawn by the device when it is idle.
When a software component executes, the current increases. The cumulative differ-
ence in these two current levels over the execution time represents the actual energy
consumption of executing a component. As an JVM platform, we used Kaffe 1.1.5
JVM [25].
6.2.2 Selecting Java Components
We have selected a large number of Java components with various characteristics for
the evaluation of our framework. They can be classified into the following three cate-
gories:
• Computation-intensive components that require a large number of CPU opera-
tions. We have used components that perform data encryption/decryption, image
processing, data compression, sorting components, and so on.
124
• Memory-intensive components that require large segments of memory at runtime.
Database and various data structure components have been selected for this type.
• Communication-intensive components that interact frequently with other compo-
nents over a network. Database and FTP client components have been chosen for
this type.
Our selection of representative Java programs is also guided by the results of existing
research [16,52], which has classified Java bytecodes into eight categories: Load,
Store, Stack, Constant pool, ALU, Branches, Jump, and Method calls. This research
suggests that most Java applications exhibit similar distributions of the eight bytecode
categories regardless of application characteristics. In particular, bytecodes belonging
to the Load, Store, and Stack categories account for more than 45% of the total num-
ber of bytecodes executed on the average. Our evaluation results to date corroborate
this: as will be seen in Section 6.2.5, the accuracy of the framework is not related to
the type of component evaluated (e.g., computation-intensive versus memory-inten-
sive).
For illustration, Table 6-1 shows a cross-section of the Java components used in our
work. These components vary in size and complexity (HSQLDB [20] is the largest,
with more than 50,000 SLOC, and Jess [23] is the second largest with 40,000 SLOC
approximately). The source code of Jess, HSQLDB, and IDEA components can be
found at Jess [23], Source Forge [66], and Java Grande Forum [22] respectively,
125
while the source code of the other components shown in Table 6-1 was obtained from
Source Bank [65].
6.2.3 Measurement
At system construction-time, we first need to measure the energy consumption of
each bytecode, native method, monitor operation, and implicit OS routine, as well as
the average energy consumption rate during garbage collection (GC). For each byte-
code we generate a Java class file that executes that bytecode 1000 times. We also
create a skeleton Java class with no functionality, which is used to measure the energy
consumption overhead of executing a class file. We use the setup discussed in
Section 6.2.1 for measuring the actual energy cost of executing both class files. We
then subtract the energy overhead E1 of running the skeleton class file from the
Table 6-1. Java-based components used in our evaluation.
Java Expert Shell System based on NASA’s
CLIPS expert shell system
Jess
Component that finds the shortest path tree
with the source location as root
Shortest Path
HSQLDB, a Java-based database engine DB
Quicksort component Sort
Data compression/decompression component
implementing the LZW algorithm
LZW
Data structure components that implement an
AVL tree and a linked list
AVL, Linked list
Component that creates a new image by
applying a median filter
Median filter
Components that encrypt or decrypt messages
by using SHA, MD5, and IDEA algorithms
SHA, MD5, IDEA
Description Component
Java Expert Shell System based on NASA’s
CLIPS expert shell system
Jess
Component that finds the shortest path tree
with the source location as root
Shortest Path
HSQLDB, a Java-based database engine DB
Quicksort component Sort
Data compression/decompression component
implementing the LZW algorithm
LZW
Data structure components that implement an
AVL tree and a linked list
AVL, Linked list
Component that creates a new image by
applying a median filter
Median filter
Components that encrypt or decrypt messages
by using SHA, MD5, and IDEA algorithms
SHA, MD5, IDEA
Description Component
126
energy cost E2 of the class file with the profiled bytecode. By dividing the result by
1000, we get the average energy consumption of executing the bytecode.
Similarly, for measuring the energy consumption of each native method, we generate
a class file invoking the native method and measure its actual energy consumption
E3. Note that when JVM executes this class file, several bytecodes are also executed.
Therefore, to get the energy cost of a native method, we subtract (E1 + energy cost of
the bytecodes) from E3. For a monitor operation, we generate a class file invoking a
method that should be synchronized among multiple threads, and measure its energy
consumption E4. Since several bytecodes are also executed during the invocation, we
can get the energy cost of a monitor operation by subtracting (E1 + energy cost of the
bytecodes) from E4.
To measure the energy consumption of implicit OS routines, we employ the approach
suggested by Tan et al. [71], which captures the energy consumption behavior of
embedded operating systems. Using this approach we are able to determine the
energy cost of major implicit OS routine calls, such as context switch, paging, and
process scheduling. For example, we conducted two separate experiments for measur-
ing the energy consumption of a context switch. For the first experiment, we created
two tasks connected together via two separate IPC channels. A single byte of data is
exchanged repeatedly between these two tasks through the IPC channels, resulting in
repeated context switches between the two tasks. For the second experiment, we
127
placed two IPC channels in a single task. Since a single byte is read or written contin-
uously within a single task via two IPC channels, no context switch occurs. We then
estimate a context switch’s energy consumption by comparing the energy costs mea-
sured in these two experiments.
Finally, for getting the average energy consumption rate of the GC thread, we execute
over a given period of time a simple Java class file that creates a large number of
“dummy” Java objects, and measure the average energy consumption rate during the
garbage collection phase via the digital multimeter.
6.2.4 Monitoring Overhead
We have measured the energy overhead due to the monitoring activities detailed in
Chapter 5 for the worst case (i.e., type III interfaces) that requires monitoring the
numbers of bytecodes, native methods, and monitor operations in addition to the GC
thread’s execution time and the number of implicit OS routines executed. The average
energy overhead compared with the energy consumption without any monitoring was
3.8%. We should also note that this overhead is transient: engineers can choose to
monitor systems during specific time periods only (e.g., whenever any changes occur
in the system or in its usage).
In order to evaluate the impact of infrastructure overhead, we performed our experi-
ments in the most extreme case, where each component is running in a separate JVM
process, thus resulting in the maximum number of implicit OS routine calls. Based on
128
our results, which are detailed in the next section, even in these cases the overall
infrastructure energy overhead is less than 4% of a distributed software system’s
energy consumption. This also allowed us to evaluate the efficiency of our monitoring
approach in the most extreme case. In addition to this we have performed a large
number of experiments that were more representative of real Java systems, in which
multiple components execute in a single JVM process. The results of those measure-
ments were on par with those we report in the next section, with the exception that
monitoring and infrastructure overheads were further reduced.
6.2.5 Evaluation Results
In this section, we present the results of evaluating our framework in estimating the
energy consumption of component-based distributed systems implemented in Java.
-6
-4
-2
0
2
4
6
1 2 3 4 5 6 7 8 9 10 11
Error rate (%)
Jess
7
Sort
6
DB
8
Shortest
path
9
AVL
10
LZW
5
Linked
List
Median
Filter
IDEA MD5 SHA
11 4 3 2 1
Jess
7
Sort
6
DB
8
Shortest
path
9
AVL
10
LZW
5
Linked
List
Median
Filter
IDEA MD5 SHA
11 4 3 2 1
Error Rate = (estimated cost – actual cost) *100 / actual cost
Figure 6-14: Error rates of the framework for the components shown in Table 6-1.
129
6.2.5.1 Computational Energy Cost
To validate our computational energy model, we compare the values calculated from
Equation 5-2 with the actual energy costs. In this section, all of the actual energy costs
have been calculated by subtracting the infrastructure energy overhead estimated by
Equation 5-6 from the energy consumption measured by the digital multimeter. As an
illustration, Figure 6-14 shows the results for components of Table 6-1. For each
component, we have executed each of its interfaces 20 times separately with different
input parameter values, and averaged the discrepancies between the estimated and
actual costs (referred to as our model’s “error rate” below). The results show that our
estimates fall within 5% of the actual energy costs. These results are also corrobo-
rated by experiments performed on additional Java components [22,65,66].
Figure 6-15: Error rates with respect to the number of simultaneously running components.
Error Rate = (estimated cost – actual cost) *100 / actual cost
-6
-4
-2
0
2
4
2 4 6 8 10
Number of simultaneously running components
Error rate (%)
130
In addition to executing components of Table 6-1 in isolation, we have run these com-
ponents simultaneously in different sample applications. Recall that, since each com-
ponent is running in a separate JVM process, the energy overhead due to implicit OS
routines is higher when multiple components are running simultaneously than when
each is running in isolation. Figure 6-15 shows the error rates of our computational
energy model as the number of simultaneously running components increases. The
experimental results show that, despite the increased infrastructure overhead, our esti-
mates usually fall within 4% of the actual energy costs.
As discussed in Section 5.3.1, multiple regression can be used for characterizing the
energy consumption of invoking type II interfaces. For this we used a tool called
Figure 6-16: Multiple regression for the find interface of the Shortest Path component.
Estimated (μJ)
Actual (μJ)
119767
122688
Point 1
261905
245395
Point 2
351300
364891
Point 3
224201
215760
Point 4
341570
316622
Point 5
677319
710709
Point 6
X2 (Num. of edges)
Y (Energy, μJ)
Y (Energy, μJ)
X1 (Num. of nodes
)
1
2
3
4
5
6
131
DataFit [3]. In measurements we conducted on various type II interfaces, our esti-
mates of their energy consumption have been within 5% of the actual energy costs. As
an illustration, Figure 6-16 shows the graph generated by DataFit for the find inter-
face of the Shortest Path component, using 20 sets of sample values for
find’s input parameters (x
1
and x
2
), and the resulting energy costs (y) estimated by
Equation 5-2. Several actual energy costs are shown for illustration as the discrete
points on the graph.
For estimating the energy consumption of type III interfaces, as discussed previously
we generated a set of random inputs, estimated the energy cost of invoking each inter-
face with the inputs using Equation 5-2, and calculated its average energy consump-
tion. Figure 6-17 compares the average energy consumption of each interface for the
DB and Jess components calculated using our framework with the interface’s actual
average energy consumption. The results show that our estimates are within 5% of the
Figure 6-17: Accuracy of the framework for type III interface of DB and Jess components.
0
500
1000
1500
Avg. Energy (mJ)
Actual 245.5 483.3 957.2 829.1 1289.8
Estimated 234.3 461.4 925.2 842.3 1335.5
DB insert DB query DB update
Jess
defineRule
Jess
runRules
132
actual average energy costs. Recall that these design-time energy estimates can be
refined at runtime by monitoring the numbers of bytecodes, native methods, and
monitor operations executed. For example, for a scenario that will be detailed in Sec-
tion 6.2.5.3, we refined the construction-time energy estimate for the DB query
interface at runtime, reducing the error rate to under 2.5%.
6.2.5.2 Communication Energy Cost
For evaluating the communication energy cost, we use a wireless router for the iPAQ
to communicate with an IBM ThinkPad X22 laptop via a UDP socket implementation
over a dedicated wireless network.
Recall from Chapter 5 that several parameters (tEC, rEC, tS, and rS) from Equation 5-
4 are platform-specific. To quantify these parameters for the iPAQ, we created two
Java programs that exchange messages via UDP sockets over the network, and exe-
cuted them on the iPAQ and the laptop. We then used the digital multimeter to mea-
sure the actual energy consumption E on the iPAQ as a result of transmitting and
receiving a sample set of messages of various sizes to/from the laptop. Since several
bytecodes and native methods (e.g., java.net.SocketInputStream’s
read() method) are executed during the program execution on the iPAQ, we sub-
tract their energy costs from E to get the energy consumption of a wireless interface
card on the iPAQ. Based on these results, we used multiple regression to find equa-
tions that capture the relationship between the input (size of the transmitted or
133
received data x) and the output (actual energy consumption y of a wireless interface
card on the iPAQ):
Eq. 6-1
Eq. 6-2
We then used the generated equations to quantify the platform-specific parameters in
Equation 5-4. For example, the size of transmitted data x
t
in Equation 6-1 represents
tEvtSize in Equation 5-4. The constant energy cost of 3.1958 represents the parameter
tS in Equation 5-4, which is independent of the size of transmitted data. The variable
Figure 6-18: Transmission (top) and receipt (bottom) energy estimation on an iPAQ.
( ) 4.0131* ( ) 3.1958
t t
y mJ x KB = +
( ) 3.9735* ( ) 5.3229
r r
y m J x KB = +
134
tEC in Equation 5-4 is captured by the constant factor 4.0131. Figure 6-18 shows two
graphs plotted for Equation 6-1 and Equation 6-2, respectively, which represent the
framework’s estimates. We can then verify the framework’s estimates against the
actual energy measurements, which are depicted by the discrete points in the figure.
The estimates from the graphs are usually within 3% of the actual energy costs.
6.2.5.3 Overall Energy Cost
Figure 6-19 shows one example of distributed applications deployed across three
iPAQ hosts. These iPAQ devices communicate with each other via a wireless router.
Each software component interacts with the other components via a UDP socket. A
line between two components (e.g., IDEA and FTP Client on host A) represents
an interaction path between them. The FTP Client and FTP Server components used
in our evaluation are UDP-based implementations of a general purpose FTP, which
Figure 6-19: A distributed Java-based mobile application comprising three hosts.
DB
Client
iPAQ (host A)
Wireless
router
FTP
Client
IDEA
LZW
DB
Server
IDEA
FTP
Server
IDEA
LZW
iPAQ (host B)
iPAQ (host C)
DB
Client
iPAQ (host A)
Wireless
router
FTP
Client
IDEA
LZW
DB
Server
IDEA
FTP
Server
IDEA
LZW
iPAQ (host B)
iPAQ (host C)
135
relies on TCP. There are two main execution paths that we have used in this particular
distributed software system:
• Database query processing — The DB Client component invokes the encrypt
interface of the IDEA component located on the same host for encrypting a query
string. Once the encrypted string is returned to DB Client, it invokes the query
interface of the remote DB Server. In response, the DB Server’ s query interface
invokes the decrypt interface of its local IDEA component to decrypt the query
string received from host A. After the query interface has calculated the results of
the query, it invokes IDEA’s encrypt interface and returns the encrypted results to
DB Client. Finally, DB Client invokes the decrypt interface of its collocated IDEA
component to get the results.
• FTP request processing — The FTP Client component requests a file from the
remote FTP Server by invoking its processRequest interface and sending the
name of the desired file in a message. The FTP Server’s processRequest interface
retrieves the file, invokes its local LZW component’s compress interface, and
transmits the compressed file back to FTP Client. FTP Client then decompresses
the file by calling its local LZW’s decompress interface. If FTP Server also
encrypts a sensitive file by invoking its local IDEA component’s encrypt inter-
face, then FTP Client will also invoke its local IDEA’s decrypt interface.
In the above application, we assume that the system’s runtime properties (e.g., inputs
to each interface, their sizes and frequencies, etc.) are not known during system con-
136
struction-time. Therefore, as construction-time energy estimates wouldn’t be close to
the system’s actual energy consumption at runtime, our framework should be able to
estimate the system’s energy consumption by monitoring the system’s properties dur-
ing runtime. For evaluating our framework’s runtime estimation capability, we have
executed the above distributed software system by varying the frequencies and sizes
of messages exchanged among the components. We have measured the system’s over-
all energy consumption using the multimeter and compared it with our framework’s
runtime estimates. As shown in Figure 6-20, the framework’s estimates always fell
within 5% of the actual energy costs regardless of interaction frequencies and the
Figure 6-20: Error rates of the framework with respect to the interaction frequency (top) and
the average size of a message (bottom).
Error Rate = (estimated cost – actual cost) *100 / actual cost
-6
-4
-2
0
2
4
6
1.1 2.1 3.4 4.2 5.1
Frequency (times/sec)
Error rate (%)
-3
-2
-1
0
1
2
3
3.3 6.2 12.2 18.3 24.4
Avg. size of a message (KB)
Error rate (%)
Error Rate = (estimated cost – actual cost) *100 / actual cost
-6
-4
-2
0
2
4
6
1.1 2.1 3.4 4.2 5.1
Frequency (times/sec)
Error rate (%)
-3
-2
-1
0
1
2
3
3.3 6.2 12.2 18.3 24.4
Avg. size of a message (KB)
Error rate (%)
137
average size of a message. In addition, we have extended the above application by
placing more hosts that have the same components as in host A, and executed the
extended application by varying the interaction frequencies and the average size of a
message exchanged between components. As shown in Figure 6-21, our framework’s
estimates were within 4% of the system’s actual energy consumption regardless of the
numbers of the system’s constituent components and hosts.
Note that, even though previous research has shown a distributed system’s communi-
cation costs to be a significant factor in its overall energy costs, our experience indi-
cates that communication costs need not be the dominant energy cost factor for a
given component or system. Whether a given software component, or system, is com-
putation-intensive, communication-intensive, or both depends on its various charac-
teristics and its usage profile. For example, consider again the distributed system
Figure 6-21: Error rates of the framework with respect to the numbers of hosts and components
0
0.5
1
1.5
2
2.5
3
3.5
5 hosts, 17
components
7 hosts, 25
components
9 hosts, 33
components
Error rate (%)
Error Rate = (estimated cost – actual cost) *100 / actual cost
138
shown in Figure 6-19. If all the requests from DB Client are database query state-
ments with the average size of 1 KB while the average size of responses from DB
Server is 10 KB, we can calculate the average communication energy cost of DB
Server from Equations 6-1 and 6-2 to be 52.6 mJ (43.3 mJ + 9.3 mJ). On the other
hand, the average computational energy cost of DB Server’s query interface is
483.3 mJ as shown in Figure 6-17. This indicates that the computational cost in this
application would be the dominant factor of DB Server’s overall energy consump-
tion.
As another application, we have built the distributed sensor application shown in
Figure 6-22, which is similar to that in Figure 6-6. In this application, we assume that
Figure 6-22: A distributed Java-based sensor application.
iPAQ (host A)
Fire
Alarm
Analyzer
Fire
Alarm
Receiver
iPAQ (host B) iPAQ (host C)
Alarm
Logger
Intrusion
Alarm
Analyzer
Global
SensorInfo
Mgmt
Local
SensorInfo
Mgmt
Local
SensorInfo
Mgmt
Intrusion
Alarm
Receiver
Wireless
router
139
the system’s runtime properties (e.g., sizes and frequencies of periodic fire and intru-
sion alarms) are known during system construction-time. Therefore, construction-
time energy estimates should be close to the system’s actual energy consumption dur-
ing runtime. For evaluating our framework’s construction-time estimation ability, we
have executed the above sensor system by varying the frequencies of messages
exchanged between components. We have then measured the system’s overall energy
consumption using the multimeter and compared it with our framework’s energy con-
sumption estimates made at construction-time. As shown in Figure 6-23, our con-
struction-time estimates were always within 5% of the actual energy costs measured
at runtime regardless of interaction frequencies.
Figure 6-23: Error rates of the framework with respect to the interaction frequency.
-6
-4
-2
0
2
4
6
0.7 1.3 2.3 3.3 5
Frequency (times/sec)
Error rate (%)
Error Rate = (estimated cost – actual cost) *100 / actual cost
140
CHAPTER 7: Conclusions
In this chapter, we first summarize the contributions of this dissertation in characteriz-
ing the energy consumption behavior of a component-based distributed system
throughout its development cycle (design-time, construction-time, and runtime). We
then discuss several possible extensions of our current work, which will pave the way
to our future work.
7.1 Contributions
As mentioned earlier, most of previous approaches to modeling and estimating the
energy consumption of embedded software have focused on specific hardware and
OS platforms. In addition, a majority of previous energy saving techniques merely
considered reducing the energy consumption incurred by individual user applications
on a single device. Consequently, none of these approaches are adequate for enabling
an engineer to build energy-efficient component-based distributed systems intended
to run on heterogeneous computing platforms, throughout the entire system life cycle,
comprising design-time, construction-time, and runtime.
For addressing the above problem, we first suggested the framework that can estimate
the energy cost induced by a distributed system’s architectural styles. The framework
is intended to be used during design-time, which would enable an engineer to use
energy consumption estimates, along with other quality attributes, in determining the
141
most appropriate style (or styles) for a target distributed system among its candidate
styles. We have applied the framework on five distributed systems styles [45,9] to
date: client-server, publish-subscribe, peer-to-peer, C2, and pipe-and-filter. Our eval-
uation results show that (1) the framework was consistently able to correctly rank the
above five styles and estimate the relative differences in their energy costs; and (2)
energy consumption estimates from the framework always fell within 7% of the
actual energy consumption resulting from each style.
Secondly, we presented a framework that estimates the energy consumption of a com-
ponent-based distributed system implemented in Java at the level of its components,
both during system construction-time and during runtime. One novel aspect of our
estimation framework is its component-based development perspective, which ren-
ders it well suited for distributed, embedded, mobile and pervasive applications, and
supports various energy-saving techniques (e.g., energy-efficient deployment map-
ping of components onto their target hosts, offloading energy-intensive components,
etc.) at the level of components. We have evaluated our framework for accuracy on a
large number of distributed Java applications, by comparing its estimates against
actual electrical current measurements. Our results show that the framework is always
able to estimate the power consumed by a distributed Java system to within 5% of the
actual consumption.
142
7.2 Future Work
The work presented in this dissertation can be extended and enhanced in several
ways. Below we describe three directions in which we intend to expand this research.
Firstly, in cases where energy efficiency is not the sole important quality attribute, an
engineer should perform trade-off analyses of multiple, possibly conflicting key qual-
ity attributes in determining the most appropriate architectural style for a target dis-
tributed system. Therefore, we plan to extend our style-induced energy estimation
framework in order to quantify other quality attributes (e.g., latency, reliability, avail-
ability, etc.) resulting from a distributed system’s architectural styles, and conse-
quently enable an engineer to perform trade-off analyses on those quality attributes.
Secondly, as our energy estimation framework for distributed Java-based systems can
keep track of the system’s overall energy consumption at the level of its components
during runtime, we plan to design and implement various component-level adaptation
techniques (e.g., offloading components that are unimportant but consuming lots of
energy, redeploying highly energy-intensive components to hosts with more remain-
ing battery power, reducing the quality level of an output produced by a component,
etc.) for saving and balancing the distributed system’s energy resources during runt-
ime. Moreover, we will also investigate how to decide automatically which adapta-
tion technique should be triggered during a certain period by considering various
143
aspects (e.g., users’ preferences, the system’s available resources, other quality
attributes, and so on).
Although Java is being increasingly used for developing distributed, pervasive, and
mobile software systems, certain types of software systems will still call for solutions
in languages such as C and C++ because of their expected better performance and
lower energy consumption. As part of our future work, we plan to extend the current
estimation framework to support estimating the energy consumption of a component-
based distributed system implemented in C or C++ at the level of its components both
during system construction-time and during runtime.
144
REFERENCES
1. P. D. Allison. Multiple regression. Pine Forge Press. 1999.
2. ARM Linux. http://www.arm.linux.org.uk/, 2005.
3. Data Fit 8.1. http://www.oakdaleengr.com/, 2006.
4. L. Dobrica, et al. A Survey on Software Architecture Analysis Methods. IEEE
Transactions on Software Engineering, July 2002.
5. W. Drytkiewicz, et al. pREST: a REST-based protocol for pervasive systems.
In Proc. of IEEE International Conference on Mobile Ad-hoc and Sensor
Systems, 2004.
6. G. Edwards, et al. Scenario-Driven Dynamic Analysis of Distributed
Architectures, In Proceedings of International Conference on Fundamental
Approaches to Software Engineering (F ASE), 2007
7. JK. I. Farkas, J. Flinn, G. Back, D. Grunwald, and J. Anderson. Quantifying
the Energy Consumption of a Pocket Computer and a Java Virtual Machine.
In Proceedings of the International Conference on Measurement and
Modeling of Computer Systems (ACM SIGMETRICS), 2000.
8. L. M. Feeney, and M. Nilsson. Investigating the Energy Consumption of a
Wireless Network Interface in an Ad Hoc Networking Environment. In
Proceedings of IEEE INFOCOM, 2001.
9. R. Fielding. Architectural Styles and the Design of Network-Based Software
Architecture. Ph.D Thesis, UCI, June 2000.
10. K. Flautner, and T. Mudge. Vertigo: Automatic Performance-Setting for Linux.
In Proceedings of the Symposium on Operating Systems Design and
Implementation, 2002.
11. J. Flinn, S. Park, and M. Satyanarayanan. Balancing Performance, Energy, and
Quality in Pervasive Computing. In Proceedings of International Conference
on Distributed Computing Systems, 2002.
145
12. J. Flinn, and M. Satyanarayanan. PowerScope: A Tool for Profiling the
Energy Usage of Mobile Applications. Workshop on Mobile Computing
Systems and Applications, 1999.
13. J. Flinn, and M. Satyanarayanan. Managing Battery Lifetime with Energy-
aware Adaptation. ACM Transactions on Computer Systems, vol. 22, no. 2,
pp. 137-179, 2004.
14. P. Gauthier, D. Harada, and M. Stemm. Reducing Power Consumption for the
Next Generation of PDAs: It's in the Network Interface!. In Proceedings of
MoMuC’96, 1996.
15. H. Grahn, et al. Some Initial Performance Characteristics of Three
Architectural Styles. In Proceedings of International Workshop on Software
and Performance, 1998.
16. D. Gregg, J. F. Power, and J. Waldron. Platform Independent Dynamic Java
Virtual Machine Analysis: the Java Grande Forum Benchmark Suite.
Concurrency and Computation: Practice and Experience, vol. 15, no. 3-5, pp.
459-484, 2003.
17. S. Gurumurthi, A. Sivasubramaniam, M. J. Irwin, N. Vijaykrishnan, and M.
Kandemir. Using Complete Machine Simulation for Software Power
Estimation: The SoftWatt Approach. In Proceedings of the International
Symposium on High-Performance Computer Architecture, 2002.
18. S. Helal. Pervasive Java. IEEE Pervasive Computing, V ol. 1, No. 1, Jan-Mar,
2002.
19. D. P. Helmbold, D. E. Long, and B. Sherrod. A Dynamic Disk Spin-Down
Technique for Mobile Computing. In Proceedings of the international
conference on Mobile computing and networking, 1996.
20. HSQLDB 1.8.0. http://www.hsqldb.org/, 2005.
21. JamVM 1.4.5. http://jamvm.sourceforge.net/, March 2007.
22. Java Grande Forum. http://www.epcc.ed.ac.uk/javagrande/, 2005.
23. Jess, the Rule Engine for the Java Platform. http://www.jessrules.com/, 2005.
24. JDDAC – Java Distributed Data Acquisition and Control. https://
jddac.dev.java.net/, 2007.
146
25. Kaffe 1.1.5. http://www.kaffe.org/, 2005.
26. R. Kazman, et al. The Architecture Trade-off Analysis Method. In
Proceedings of International Conference on Engineering of Complex
Computer Systems, 1998.
27. R. Kazman, et al. Experience with Performing Architecture Trade-off
Analysis. In Proceedings of International Conference on Software
Engineering, 1999.
28. S. Khurshid, C. Pasareanu, and W. Visser. Generalized Symbolic Execution
for Model Checking and Testing. In Proceedings of the International
Conference on Tools and Algorithms for Construction and Analysis of
Systems, 2003.
29. S. Khurshid, and Y. Suen. Generalizing Symbolic Execution to Library
Classes. ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for
Software Tools and Engineering, 2005.
30. J. C. King. Symbolic execution and program testing. Communications of the
ACM, vo.19, no. 7, pp. 385-394, 1976.
31. KVM. http://java.sun.com/products/cldc/wp/, 2005.
32. J. J. Labrosse. MicroC/OS-II: The Real-Time Kernel. CMP Books, 2002.
33. S. Lafond, and J. Lilius. An Opcode Level Energy Consumption Model for a
Java Virtual Machine. In Virtual Machine Research and Technology
Symposium, 2004.
34. S. Lafond, and J. Lilius. An Energy Consumption Model for An Embedded
Java Virtual Machine. In Proceedings of International Conference on
Architecture of Computing Systems, 2006.
35. E. A. Lee. Embedded Software. Advances in Computers (Marvin V . Zelkowitz,
ed.), Academic Press, London, 2002.
36. S. Lee, A. Ermedahl, and S. L. Min. An Accurate Instruction-Level Energy
Consumption Model for Embedded RISC Processors. In Proceedings of the
ACM SIGPLAN workshop on Languages, compilers and tools for embedded
systems, 2001.
147
37. T. Li, and L. K. John. Run-time modeling and estimation of operating system
power consumption. In Proceedings of the International Conference on
Measurement and Modeling of Computer Systems (ACM SIGMETRICS),
2003.
38. J. Lorch, and A. Smith. Operating System Modifications for Task-Based
Speed and V oltage Scheduling. In Proceedings of the International Conference
on Mobile Systems, Applications, and Services, 2003.
39. S. Malek, M. Mikic-Rakic, and N. Medvidovic. A Style-Aware Architectural
Middleware for Resource-Constrained, Distributed Systems. IEEE Trans. on
Software Engineering, Vol. 31, No. 4, March 2005.
40. S. Malek, C. Seo, S. Ravula, B. Petrus, and N. Medvidovic.
Reconceptualizing a Family of Heterogeneous Embedded Systems via
Explicit Architectural Support. In proceedings of the 29th International
Conference on Software Engineering (ICSE 2007), Minneapolis, Minnesota,
May 2007.
41. S. Malek. A User-Centric Approach for Improving a Distributed Software
System’s Deployment Architecture. Ph.D. Dissertation, University of
Southern California, May 2007.
42. M. Mantovani, et al. A Lightweight Parallel Java Execution Environment for
Embedded Multiprocessor Systems-on-Chip. In Proc. of GLSVLSI 2007, Italy,
March 2007.
43. C. B. Margi, K. Obraczka, R. Manduchi. Characterizing system level energy
consumption in mobile computing platforms. In Proceedings of International
Conference on Wireless Networks, Communications and Mobile Computing,
2005.
44. N. Medvidovic, et al. A Classification and Comparison Framework for
Software Architecture Description Languages. IEEE Transactions on
Software Engineering, January 2000.
45. N. Mehta. Composing Style-Based Software Architectures From
Architectural Primitives. Ph.D Thesis, USC, 2004.
46. N. Mehta, et al. Towards a Taxonomy of Software Connectors. In Proceedings
of International Conference on Software Engineering, Limerick, Ireland,
June, 2000.
148
47. M. Mikic-Rakic, S. Malek, and N. Medvidovic. Improving Availability in
Large, Distributed Component-Based Systems via Redeployment. In
Proceedings of the International Working Conference on Component
Deployment, Nov. 2005.
48. D. Narayanan, and M. Satyanarayanan. Predictive Resource Management for
Wearable Computing. In Proceedings of the International Conference on
Mobile Systems, Applications, and Services, 2003.
49. NetBSD Project. http://www.netbsd.org/, 2005.
50. R. Neugebauer, et al. Energy is Just Another Resource: Energy Accounting
and Energy Pricing in the Nemesis OS. In Proceedings of the IEEE Workshop
on Hot Topics in Operating Systems, 2001.
51. D.E. Perry, et al. Foundations for the Study of Software Architectures.
Software Engineering Notes, Oct. 1992.
52. R. Radhakrishnan, N. Vijaykrishnan, L. K. John, A. Sivasubramaniam, J.
Rubio, and J. Sabarinathan. Java Runtime Systems: Characterization and
Architectural Implications. IEEE Transactions on Computers, vol. 50, no. 2,
pp. 131-146, 2001.
53. M. Rosenblum, S. A. Herrod, E. Witchel, and A. Gupta. Complete Computer
System Simulation: The SimOS Approach. IEEE Parallel and Distributed
Technology: Systems and Applications, vol. 3, no. 4, pp. 34-43, 1995.
54. A. Rudenko, P. Reiher, G. J. Popek, and G. H. Kuenning. The Remote
Processing Framework for Portable Computer Power Saving. In Proceedings
of ACM Symposium on Applied Computing, 1999.
55. D. C. Schmidt, et al. Patterns and Performance of Distributed Real-time and
Embedded Publisher/Subscriber Architectures. Journal of Systems and
Software, Oct. 2002.
56. C. Seo, et al. A Framework for Estimating the Impact of a Distributed
Software System's Architectural Style on its Energy Consumption. In
Proceedings of Working IEEE/IFIP Conference on Software Architecture
(WICSA 2008), Vancouver, Canada, February 2008.
57. C. Seo, et al. An Energy Consumption Framework for Distributed Java-Based
Systems. In Proceedings of ACM/IEEE International Conference on
Automated Software Engineering, Atlanta, Georgia, Nov. 2007.
149
58. C. Seo, et al. Estimating the Energy Consumption in Pervasive Java-Based
Systems. In Proceedings of IEEE International Conference on Pervasive
Computing and Communication (PerCom 2008), Hong Kong, March 2008.
59. M. Shaw, et al. A Field Guide to Boxology: Preliminary Classification of
Architectural Styles for Software Systems. In Proceedings of International
Computer Software and Applications Conference, 1997.
60. M. Shaw and D. Garlan. Software Architecture: Perspectives on an Emerging
Discipline. Prentice Hall, 1996.
61. SGI IRIX 5.3. http://lidar.ssec.wisc.edu/~forrest/cdwrite-sgi.html, 2005.
62. G. Sinevriotis, A. Leventis, D. Anastasiadou, C. Stavroulopoulos, T.
Papadopoulos, T. Antonakopoulos, and T. Stouraitis. SOFLOPO: Towards
Systematic Software Exploitation for Low-Power Designs. In International
Symposium on Low Power Electronics and Design, 2000.
63. H. Singh, S. Saxena, and S. Singh. Energy Consumption of TCP in Ad Hoc
Networks. Wireless Networks, vol. 10, no. 5, pp. 531-542, 2004.
64. A. Sinha, et al. JouleTrack - A Web Based Tool for Software Energy Profiling.
In Proceedings of DAC, 2001.
65. SourceBank. http://archive.devx.com/sourcebank/, 2005.
66. sourceForge.net. http://sourceforge.net/, 2005.
67. J. P. Sousa, et al. Aura: an Architectural Framework for User Mobility in
Ubiquitous Computing Environments. WICSA 2002, Montreal, August 2002.
68. Spec JVM98 Benchmarks. http://www.spec.org/jvm98/, 2001.
69. Sun Labs Virtual Machine for Research. http://www.sun.com/research/java-
topics, 2001.
70. TAO Realtime ORB. http://www.cs.wustl.edu/~schmidt/TAO.html, 2006.
71. T. K. Tan, A. Raghunathan, and N. K. Jha. Energy macromodeling of
embedded operating systems. ACM Transactions on Embedded Computing
Systems, 2005.
150
72. R. N. Taylor, N. Medvidovic, et al. A component- and message-based
architectural style for GUI software. IEEE Transactions on Software
Engineering, V ol. 22, No. 6, 1996.
73. V. Tiwari, and T. C. Lee. Power Analysis of a 32-bit Embedded
Microcontroller. VLSI Design Journal, vol. 7, no. 3, 1998.
74. V. Tiwari, S. Malik, and A. Wolfe. Power Analysis of Embedded Software: a
First Step Towards Software Power Minimization. IEEE Transactions on
Very Large Scale Integration Systems, vol. 2, no. 4, pp. 437-445, 1994.
75. UFTP, http://www.tcnj.edu/~bush/uftp.html, 2007.
76. UPnP Device Architecture, http://www.upnp.org/, 2007.
77. N. Vijaykrishnan, M. Kandemir, S. Tomar, S. Kim, A. Sivasubramaniam, and
M. J. Irwin. Energy Behavior of Java Applications from the Memory
Perspective. In Proceedings of the Java Virtual Machine Research and
Technology Symposium, 2001.
78. W. Visser, C. S. Pasareanu, and S. Khurshid. Test Input Generation with Java
PathFinder. In Proceedings of the ACM SIGSOFT international symposium
on Software testing and analysis, July 2004.
79. B. Wang, and S. Singh. Computational Energy Cost of TCP. In Proceedings
of IEEE INFOCOM, 2004.
80. W. Wang, et al. Software Architectural Analysis - A Case Study. In
Proceedings of International Computer Software and Applications
Conference, 1999.
81. A. Weissel, B. Beutel, and F. Bellosa. Cooperative I/O: A Novel I/O
Semantics for Energy-Aware Applications. In Proceedings of the Symposium
on Operating Systems Design and Implementation, 2002.
82. R. Xu, Z. Li, C. Wang, and P. Ni. Impact of Data Compression on Energy
Consumption of Wireless-Networked Handheld Devices. In Proceedings of
the International Conference on Distributed Computing Systems, 2003.
83. H. Zeng, et al. ECOSystem: Managing Energy as a First Class Operating
System Resource. ACM ASPLOS, 2002.
151
84. Y. Zhang, X. Hu, and D. Z. Chen. Task Scheduling and Voltage Selection for
Energy Minimization. In Proceedings of Design Automation Conference,
2002.
85. D. Zhu, R. Melhem, and B. Childers. Scheduling with Dynamic Voltage/
Speed Adjustment Using Slack Reclamation in Multi-Processor Realtime
Systems. In Proceedings of IEEE Real-Time Systems Symposium, 2001.

Abstract (if available)

Abstract Component-based distributed systems are increasingly deployed onto heterogeneous embedded platforms with limited battery resources. In this domain, it is crucial to provide an effective approach that enables an engineer to build energy-efficient component-based distributed systems throughout the entire development cycle spanning system design-time, construction-time, and runtime. To address this problem, this dissertation first presents a framework that (1) facilitates early estimation of the energy consumption induced by an architectural style in a component-based distributed system, and (2) consequently enables an engineer to use energy consumption estimates along with other quality attributes in determining the most appropriate style for a given distributed system during design-time.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

A user-centric approach for improving a distributed software system's deployment architecture

PDF

Energy-efficient shutdown of circuit components and computing systems

PDF

Policy based data placement in distributed systems

PDF

Software connectors for highly distributed and voluminous data-intensive systems

PDF

Energy efficient design and provisioning of hardware resources in modern computing systems

PDF

Detecting anomalies in event-based systems through static analysis

PDF

Component-based distributed data stores

PDF

Design-time software quality modeling and analysis of distributed software-intensive systems

PDF

Domain-based effort distribution model for software cost estimation

PDF

Reducing inter-component communication vulnerabilities in event-based systems

PDF

Adaptive resource management in distributed systems

PDF

Deriving component‐level behavior models from scenario‐based requirements

PDF

Self-assembly for discreet, fault-tolerant, and scalable computation on internet-sized distributed networks

PDF

Landscape and building solar loads: development of a computer-based tool to aid in the design of landscape to reduce solar gain and energy consumption in low-rise residential buildings

PDF

Energy optimization of mobile applications

PDF

A synthesis approach to manage complexity in software systems design

PDF

Calculating architectural reliability via modeling and analysis

PDF

Automated synthesis of domain-specific model interpreters

PDF

Economic model predictive control for building energy systems

PDF

Quantitative and qualitative analyses of requirements elaboration for early software size estimation

Asset Metadata

Creator Seo, Chiyoung (author)

Core Title Prediction of energy consumption behavior in component-based distributed systems

School Viterbi School of Engineering

Degree Doctor of Philosophy

Degree Program Computer Science

Publication Date 05/23/2008

Defense Date 04/09/2008

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag architectural styles,component-based distributed systems,energy consumption,JAVA,OAI-PMH Harvest

Language English

Advisor Medvidovic, Nenad (committee chair), Boehm, Barry W. (committee member), Parker, Alice C. (committee member)

Creator Email cseo@usc.edu

Permanent Link (DOI) https://doi.org/10.25549/usctheses-m1245

Unique identifier UC1169653

Identifier etd-Seo-20080523 (filename),usctheses-m40 (legacy collection record id),usctheses-c127-79138 (legacy record id),usctheses-m1245 (legacy record id)

Legacy Identifier etd-Seo-20080523.pdf

Dmrecord 79138

Document Type Dissertation

Rights Seo, Chiyoung

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Repository Name Libraries, University of Southern California

Repository Location Los Angeles, California

Repository Email cisadmin@lib.usc.edu