This article has been accepted for publication in a future issue of this journal, but has not been

fully edited. Content may change prior to final publication.

IEEE TRANSACTIONS ON SERVICES COMPUTING
1

Power-Aware Cloud Metering

Akshay Narayan and Shrisha Rao, Member, IEEE

Abstract—The cost of electricity contributes significantly to the operating expense incurred in hosting cloud services. It is necessary
to consider this cost while charging the consumers for their service utilization. In this work, we arrive at a metering mechanism for
cloud services, in which the price of a cloud service tracks the variable input cost of electricity from a smart grid. The power-aware
cloud metering developed here is a dynamic pricing and billing model where tariff for a cloud service is varied in accordance with the
input electricity cost. We arrive at a model for power consumption of virtual machines hosted on the cloud infrastructure. This power
consumption model is used in calculating the cost of operation of the service. A cloud instance leased by a consumer is billed based
on the cost of operation obtained, and its resource utilization. Experimental results validate the approach presented.

Index Terms—cloud computing, smart grid, power-aware metering, billing, resource management, power consumption regulation

1 I NTRODUCTION the mapping between the input electricity cost and the
output price of the cloud service. The problem is of

T HE CLOUD computing paradigm has gained

momentum owing to the development of
virtualization technology. Virtualization is the process of
creating virtual copies of resources that can be deployed
over a physical server. The tangible unit of cloud
service, a cloud instance, is a virtual machine (VM)
deployed over the infrastructure. Cloud computing
provides for availing a set of computing resources such
as compute power, network, memory and storage space
over the Internet by individuals or organizations for a
fee. These services are hosted in large-scale data centers
by service providers and are sold on demand, both in
terms of duration and quantity.
The service provider incurs a cost in terms of electricity,
equipment and personnel in hosting the services over
the Internet. The capital expenditure (CapEx) is the fixed
cost of machinery, facilities, etc., while the operating
expenditure (OpEx) which is much larger over a period
of time [1] comprises for the most part the cost of
electricity. The cost of the electrical infrastructure for
running data centers is quite large, often exceeding the
cost of IT equipment, as such infrastructure is quite
sophisticated [2], and the running cost of electricity
over a period of time handily exceeds the cost of
equipment and infrastructure [3]. Power consumption
in data centers is a major concern [4], [5], [6], [7].
Power consumption at the VM level (rather than over
individual servers or whole data centers) is also of
interest [8], [9].
Thus, the pricing of cloud services offered to the
consumer should consider the cost of electricity as a
guiding factor. Here we describe a method to achieve
• Akshay Narayan is with School of Computing, National University of
Singapore. E-mail: anarayan@comp.nus.edu.sg
• Shrisha Rao is with International Institute of Information Technology
Bangalore. E-Mail: shrao@ieee.org
particular interest here because the cost of electricity is
time-variant and dynamic owing to the presence of smart
meters [10], [11]. In our solution, we determine the power
consumption of individual VMs and based on the cost
of electricity at that instant of time, calculate the fee to
be levied to the consumer. Hence we arrive at a solution
which tracks the output price of the service as per the
varying input cost of electricity.
In 2007, the electricity consumption in data centers was
recorded as 12 GW (giga watts); in 2011, the recorded
power consumption was 31 GW [12], almost thrice that
of 2007. In 2012, the power consumption exceeded the
predicted value of 19% increase, and grew by 63%
globally [13], [14]. As can be seen from various reports,
the power demand of data centers is increasing at a fast
pace. With this in consideration, it is extremely important
to make server farms or data centers (in this paper, we
use “server farm” and “data center” interchangeably)
hosting the cloud power-aware. Cloud infrastructure
management involves various tasks like: (i) provisioning
VMs (or cloud instances); (ii) workload placement;
(iii) scheduling cloud instances; and (iv) monitoring and
metering.
Each of these tasks can be made power-aware. Power
awareness in provisioning of VMs is discussed in [9].
Optimal workload placement for energy efficiency has
been dealt in detail in [15], [16]. Various methods of
scheduling VMs on a cloud infrastructure, like powering
off idle servers hosting VMs [17], are seen. Our focus
in this work is limited to the monitoring and metering
aspects of power awareness in data centers. Some work
on metering cloud services based on infrastructure
utilization but without reference to power consumption,
is discussed elsewhere [18]. In this work, we develop a
metering mechanism for the cloud infrastructure which
tracks the input electricity cost payable to a smart grid.
Qureshi et al. [19] highlight the importance of using

Digital Object Indentifier 10.1109/TSC.2013.22 1939-1374/13/$31.00 © 2013 IEEE

 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
IEEE TRANSACTIONS ON SERVICES COMPUTING
the variability of electricity price across geographies to
reduce data center costs. Our work extends the idea to
vary the charge on the consumers based on the variation
in electricity costs.
In this paper we describe a power-aware metering
mechanism for cloud services. This approach caters to
the need for a dynamic pay-per-use model in the cloud
environment based on real-time pricing of electricity.
We use the analytical power model proposed by Heath
et al. [20] to arrive at the power consumption of a
cloud instance hosted on the infrastructure based on its
resource utilization. The premise of this work is to use
the variability in cost of electricity to run the data center
as a basis to determine the price of the cloud service. To
this end, this model enables us to record the resource
usage per cloud instance and to generate a bill based on
two factors, viz.,
(i) the marginal power consumption of the cloud
instance; and
(ii) the current input cost of electricity as specified by
the smart power grid/source.
Studies show that the energy consumption rises and falls
with computing resource utilization [4], [5], [8], [17]. This
is one of the bases for our approach, where we use the
resource utilization to determine the power consumption
of the cloud instance.
Davison et al. [21], in the course of developing a
model for electricity spot prices, indicate that the
price of electricity is seasonally variant. Power price
is guided by demand and supply factors. Alvarado
and Rajaraman [22] discuss price volatility in electricity
markets and reasons for the prevalent spot prices.
Domingues [23] sheds light on the impact of renewable
energy on the pricing of electricity in a liberalized
market. It is also known that solar energy usage leads to
variable power price [24], because, after all, solar energy
supply itself is inherently variable [25]. The same is also
true of wind energy supply [26]. Thus, as solar and
other alternative-energy sources see increasing use, we
may expect that variable power supply cost will become
an inevitable reality for all large power consumers
including IT systems used by cloud providers.
Smart meters in the power grid, also called advanced
metering infrastructures (AMI) [27], are devices that
include basic hourly interval meters, meters with
one-way communication, and real-time meters with
built-in two-way communication capable of recording
and transmitting instantaneous data. The recorded data
are provided to both consumers and energy companies
at least once daily [28]. AMI help realize time-based rates
and demand-response actions at the user end. These
devices perform real-time registrations of electricity
usage, whose data are used for billing and other
purposes. They allow obtaining the usage information
both locally and remotely. Smart metering and smart
2
tariffs are implemented in various power grids across
the globe [29].
Electricity pricing provided by smart meters [11] in
the power domain provides a starting point for us
to price cloud services. The power-aware metering
proposed in this paper aims at providing a dynamic
pricing mechanism for cloud service providers. The
service provider specifies a price based on the current
electricity cost input from the power grid and cloud
utilization using the power model described. It is then
at the consumer’s discretion to continue using the
cloud instance by paying the specified amount, or to
terminate the cloud instance. We propose to achieve
a metering mechanism analogous to the advanced
metering infrastructure in the power grids.
The computing resource needs of a cloud consumer
are time-variant, and hence the power footprint of the
consumer also varies with time. It is well known that the
cost of power is the primary cost of maintaining a large
data center and that this cost is passed on to consumers.
Given the reality of smart metering of power supplies by
electricity suppliers the world over, it therefore makes
sense for the vendor to use similar smart metering
technology to recover the cost of power from consumers.
It is also in the best interest of the consumer to have a
varying service price, as then the consumer can decide
on service utilization based on the cost. There is a need
to consider these facts while metering service utilization.
Current implementations of metering mechanisms [30],
[31], [32] in cloud environments are based on service
level agreements (SLA) or bid amounts which govern
the provisioned capacity. These are fixed-cost, post-paid
service models. The limitation of these models is that
consumers are billed based on a predefined tariff for
the utilization. This predefined tariff does not consider
the variation in the input cost of electricity. There is
no existing system that performs metering of a cloud
service with due consideration to the varying cost of
power consumption. This is our motivation to develop
power-aware metering for cloud services.
We propose a dynamic pricing scheme for cloud services
which varies according to the input cost of electricity.
Specifically, we do the following in this paper:
(i) Classify the existing power models for servers as
component-specific power models and system-level
power models, and compare them.
(ii) Arrive at a power consumption model for cloud
instances based on a system-level power model.
(iii) Develop a cost model for cloud services which
is aligned with the dynamic electricity pricing
provided by a smart grid.
(iv) Use the above to generate the dynamic price
charged for a cloud service based on the input cost
of electricity.
This work has not been done in any of the earlier
papers such as [33] which look at using electricity smart
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
IEEE TRANSACTIONS ON SERVICES COMPUTING
3

meters in data centers without considering power-aware

metering of the cloud itself.
Incorporating variation of power into cloud service
pricing introduces “price uncertainty” into the system
and can make it hard for the consumer to decide
whether to continue using the service or terminate
the instance. In order to overcome this disadvantage,
we can incorporate a price prediction mechanism for
cloud services [18], or use a predicted price of a smart
grid with suitable mechanisms [34], making appropriate
modifications to suit industrial applications such as
large-scale data centers to obtain the instantaneous price
for a cloud service that is published to consumers to aid
their decision making. Price prediction and its economic
aspects are beyond the scope of this paper, hence we do
not discuss them here.
Fig. 1. Schematic representation of a cloud system
The rest of the paper is organized as follows. We describe
the architecture of the metering mechanism proposed
and its deployment in the cloud hosting data center in
Section 2. In Section 3 we evaluate the prevalent power Monitoring of the system resource utilization is an
models for physical servers, describe the most suitable important aspect in any form of metering; power-aware
for our work and arrive at a power model for cloud metering is no exception. Monitoring for system resource
instances. It may be noted that the primary motivation utilization happens at two levels. At the infrastructure
for the previous power models described was to record level, the utilization of system resources is monitored
power consumption in servers and to minimize the and stored appropriately, so that the data are available
overall power consumption of the data center, the goal for further use during billing. Cloud instances which
our work is to use the power consumption recorded to are essentially VMs hosted on the cloud infrastructure
perform metering of the cloud service. Minimization of are monitored for their individual system resource
power consumption is thus not the main objective. The utilization. This data is also stored for use during billing.
total cost of operation for cloud service deployment, the Monitoring cycles are defined such that the sampling
pricing scheme, and billing calculations are detailed in interval is an integral factor of the duration after which
Section 4. Section 5 concerns a prototype implementation the power grid prices are updated. This time interval
of the power model and the billing calculations. Our defines the granularity of generating the bill—for
experimental results are presented in Section 6, and example, if the time interval is one hour, a bill can
Section 7 presents our conclusions. be generated every hour based on the utilization and
the dynamic price specified by the power grid. (Or the
hourly bill can be stored and added to the monthly bill.)
2 P OWER -AWARE M ETERING A RCHITECTURE
The cost model determines the operational cost of
A cloud deployment essentially consists of a controller running the infrastructure at various utilization levels.
node which maintains information about the entire It is based on this cost model that the bill amount is
deployment. This controller node is attached to various calculated. Cost modeling considers various parameters
nodes (hardware such as servers) on which the cloud like the price of electricity as prescribed by the power
instances, i.e., VMs, are installed. The internal network grid, the utilization level of the cloud infrastructure, and
of the cloud infrastructure typically utilizes private the pricing scheme specified by the service provider.
network addressing. Cloud instances are made available
to the consumers using public IP addresses. A schematic The pricing values can be supplied as a look-up table
representation of a generic cloud system deployment by the service provider. In our work, we propose to use
is as shown in Figure 1. In this work we assume that a simplified pricing scheme as explained in Section 4.2.
the servers deployed in the data center are of uniform The pricing scheme may consider the operational profit
capacity. of the service provider and related costs involved.
Consolidated monthly bills and on-demand bills are
The elements of power-aware metering can reside on
generated in the billing module. Equation (12) which
the controller and perform the metering operation, or
calculates the consolidated bill for a specified time
can be deployed on a different server. The system
period is implemented in this module. The generated
resource utilization by the VMs can be obtained using
bill is returned to the consumer.
performance counters [35] or using an off-the-shelf
monitoring tool. This architecture of the proposed system is as shown in
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
IEEE TRANSACTIONS ON SERVICES COMPUTING
Fig. 2. Power-aware cloud metering architecture
Figure 2.
3 P OWER M ODEL E VALUATION
The power consumption of a subsystem of a working
system in production environments cannot be monitored
using instrumented hardware. This is because such
instrumentation results in reduction of operational
efficiency of the system, and might also interfere with
other aspects like cooling and ease of maintenance.
Therefore, in order to determine the power consumption
of the infrastructure components in real time, it is
necessary to have a method to characterize the power
consumption. This is achieved by using a power model
which determines the system power consumption based
on certain parameters that define the system resource
utilization. These parameters are collected at run time
using software.
We classify the power models into two major
classes, viz., (i) component-specific power models;
and (ii) system-level power models.
Component/subsystem-specific power models
characterize the power consumption of such components
or subsystems accurately. However, when a system
view of power consumption is considered, the error
increases when the power consumptions of other
subsystems are not considered. Multiple such power
models may therefore be necessary to obtain the entire
system’s power consumption, which would increase the
complexity of the metering mechanism.
To circumvent the problems of loss of accuracy and
increase in complexity, we evaluate some power models
which provide a view of the system-level power
consumption. Many power models that provide system
power consumption are developed using instrumented
hardware. Owing to the fact that it is impossible to
deploy instrumented hardware in production systems
4
for reasons stated earlier, we evaluate some analytical
power models. We draw a comparison between the
various power models that provide a system-level view.
Analytical power models are applicable to a larger
number of cloud systems. Appropriate parameters can
be chosen and the same power model can be used
with minor or no changes in a system with different
hardware deployment. It is important to choose a power
model which provides a right balance of ease of use and
effectiveness in the metering mechanism.
Further, there exists no analytical model for power
consumption of a cloud instance. We derive the relation
between the resource utilization and power consumption
of a cloud instance in Section 3.3. For this purpose, we
make use of an analytical model [20] which provides the
relation between system resource utilization and power
consumption for a VM.
3.1 Component-Specific Power Models
Lefurgy et al. [36] for example study power consumption
of memory and microprocessor subsystems of
commercial servers. Energy consumption is based
on the structured workloads and there is a system-wide
approach to reduce the power consumption. Bianchini
and Rajamony [37] provide an exhaustive survey
of the then state-of-the-art mechanisms for power
consumption. These are some of the earlier attempts at
power modeling the data center hardware. Some of the
more recent work can be characterized as following.
Ranganathan et al. [38] determine the power
consumption of the system by estimating the power
consumption of the CPU. The argument presented is
that the CPU is the greatest consumer of power in a
blade server, and hence the system power consumption
is determined using the processor power consumption
within an error bound of 10%. The approach followed
by them is to determine the 90th percentile resource
utilization and multiply it by the rated power for the
system. The results obtained in their work involve
significant levels of approximation.
Deng et al. [39] derive a relation for memory power
consumption in their work based on the number of
LLC misses that occur per unit time. Memory power
consumption is determined as a sum of the power
consumption of bus, bank and the memory chip.
Though these component-specific models are accurate in
their own accord, using any of these independently in
our work results in extreme levels of approximation on
one hand while, using several of them together would
result in increasing the complexity of the metering
mechanism. Hence we evaluate the possibility of using
a system level power model, as indicated in the next
subsection.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
IEEE TRANSACTIONS ON SERVICES COMPUTING
5

Symbol Definition
Common symbols
Ptotal Total power used by the system
Pidle Power consumed when the system is idle
P Total power consumed by the cloud server farm
pj power consumed by cloud instance j
Equation (1)
Pcpu Power consumed by the CPU subsystem
Pmem Power consumed by memory subsystem
Pio Power consumed by the memory subsystem
Pnet Power consumed by the networking subsystem
Equation (3)
Pi Power consumed by the ith subsystem
fi Operating frequency of the ith subsystem
Vi Voltage used to power the ith subsystem
Equation (4)
Ppeak Power consumed when the system is at 100% utilization
Active% Activity level of the system against the full capacity
P arallelization Parallelization factor achieved in instruction execution
F etchedOps CPU performance counter which indicates the number of fetched operations per second
Cycles Number of CPU cycles per second
Equation (5)
B Power consumed when the system is idle (analogous to Pidle )
Ui Utilization of the ith subsystem
Ci Capacity of the ith subsystem
i Indicates a subsystem in the system, it is one of { cpu, memory, io, network }

TABLE 1
Symbols used in power model evaluation

Parameter / Power model category Complete Experimental Function of supplied Analytical

system view analysis voltage & frequency power model

Needs instrumented hardware Yes Yes Yes No

Approximation level High High Moderate Low
Needs calibration run Yes Yes No No
Applicable for future systems No No Yes Yes
Derive consumption per vm No No No Yes

TABLE 2
Comparison of power models

3.2 System-Level Power Models
There have been various approaches to power modeling
at a systems level. Some of these approaches use
instrumented hardware to determine the power
consumption of the component/sub-system while
others determine the power consumption of the system
empirically. A few approaches under each of these
categories are discussed in this subsection to help
appreciate the necessity of an analytical power model
rather than using an empirically determined power
model.
Complete system view for power consumption:
Recently, Choi et al. [40] describe a mechanism to
achieve power-aware application packing in large cluster
deployments. The goal of their work is to minimize the
power consumption in a data center. Jang et al. [41]
discuss energy reduction methods using memory-aware
VM scheduling. All of the above use some form of power
model to suit the need.
In the above, the power consumed is represented as the
sum of the subsystems’ power consumption.
Ptotal = Pidle + Pcpu + Pmem + Pio + Pnet (1)
A full system view of power consumption of the server
is obtained by Economou et al. [42]. This model uses the
resource utilization values of the server subsystems and
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
IEEE TRANSACTIONS ON SERVICES COMPUTING
6

obtains the power consumption as a weighted sum of

the individual resources. This power model needs an U  U 
cpu mem
offline calibration run, where the power consumption Ptotal = B + Mcpu + Mmem
Ccpu Cmem
behavior of the system is recorded. Using the results of U  U 
io net
this calibration run, power consumption of the deployed +Mio + Mnet (5)
Cio Cnet
system is calculated as:
where,
Ptotal = 14.45 + 0.236 Ucpu , + 4.47 × 10−8 Umem Ptotal = power consumed by the server in Watts,
+ 0.00281 Uio + 3.1 × 10−8 Unet (2) B = base power consumed by the server when it is
idle in Watts,
We note in (2) that the coefficients of memory and each Mi is the measure of power consumption of
network subsystems are negligible (of the order of resource i when operated at 100% capacity,
10−8 ) and hence it can be ignored. This fact is further Ui is the utilization of resource i on the server,
strengthened by the findings in [43]. Also in the power Ci is the capacity of resource i on the server and
model described above the coefficients vary from system i indicates a resource one of
to system. It is difficult to normalize those coefficients { cpu, memory, io, network }
over a large variety of systems. Essentially, (5) calculates the amount of power consumed
Experimental analysis of power consumption & by the service (CPU, storage disks, network equipment.
power characterization: An experimental approach to etc.,) over the base power necessary to keep the
determine the power consumption of servers is proposed infrastructure running, for every utilized resource. This
by Krishnan et al. [44], who use the rated power analytical model can be reduced to most other power
consumption of servers; the power consumption of each models described in the literature with little or no
resource is determined by activating that particular modification. For instance (5) can be reduced to (2) by
resource to 100% while keeping others idle. The key using the appropriate constants. If:
finding in this work is that the power consumption is B = 14.45
additive in nature for increased number of cores used in Mcpu
the system. Ccpu = 0.236
Mmem
Cmem = 4.47 × 10−8
Power consumption modeled as a function of supplied
voltage and operational frequency: Power modeling
Mio
Cio = 0.00281
of servers has been achieved in the past using Mnet
Cnet = 3.1 × 10−8
various techniques with parameters like the supplied
voltage and processor running frequency [45]. Power then we see that (5) reduces to (2).
measurements in [45] are made at particular frequencies The above is an indicative example to illustrate that
of operation. As the frequency changes, the power the analytical power model is a generalization of other
consumption changes, given by: power models discussed.
Pi ∝ fi · Vi2 (3) The total power consumption of the cloud server farm

This relation is applicable to each subsystem i in the is given by P = P
i i , where P is the total power
system, where i is one of { cpu, memory, io, network }. consumed by the server farm, and Pi is the power
consumed by machine i.
Analytical power model: Bircher and John [46] use
a subset of processor events and corresponding CPU In our work, we use (5) as the basis to determine
performance counters to determine the activity level of the power consumption of the cloud instance. This
the processor and memory subsystem. Based on the is because (1), (3) and (4) are closely tied to the
utilization level, the power consumed by the system is hardware and need some sort of calibration to accurately
calculated using the relation in (4). This model accounts characterize the power consumption of the server, but (5)
for parallelization in instruction execution. does not need any calibration run on deployment, is
generic, and is applicable to a larger class of hardware
Ptotal = Pidle + Ppeak × Active% + systems hosting cloud infrastructures.
PP arallelization× F etchedOps (4) A tabular comparison of the power models is given
Cycles

in Table 2. To develop a metering mechanism that

Heath et al. [20] derive an analytical power model
based on the resource utilization and the rated power
consumption of the system component. We use this
analytical power model to obtain a relation between the
utilization of a service and the power consumed. The
power model is described as follows,
works well in real time, the desired properties of
the power model are that it should have a low
approximation, depend on no specific hardware support
(like instrumented boards and such), and it should be
generic so that it can be applied to any cloud system.
As can be seen, it is advantageous to use an analytical
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
IEEE TRANSACTIONS ON SERVICES COMPUTING
7

power model to characterize the power consumption of discussion and (5) that the power consumed by the cloud
the cloud instances. We derive the power consumption instance is:
of a cloud instance using an analytical model for ucpu umem
servers (5). This is a generic approach without needing pj = Mcpu × + Mmem ×
Ccpu Cmem
any instrumented hardware or calibration. uio unet
+Mio × + Mnet × (6)
Cio Cnet

3.3 Cloud Instance Power Consumption
A cloud instance is essentially a VM hosted on one of
the bare metal servers in the data center. In order to
model the power utilization of a cloud consumer for the
service availed, it is necessary to determine the power
consumption of the particular cloud instance assigned to
the consumer. Cloud instances are hypervisor processes
running on the servers in the data center. Hence to
determine the instance power utilization, we monitor the
resource utilization of the process in which the cloud
instance is running.
There is no direct way to determine the power
consumption of a cloud instance. The two possible ways
of determining the power consumption of VMs are:
(i) using instrumented hardware to run a single VM
and determine the power consumed by the machine;
and (ii) estimating the power consumed by a VM by
recording its resource utilization.
Some earlier methods [9] use instrumented hardware
to host a single VM. The power consumption of the
server is recorded using instruments attached to the
server. Power consumption of the server while idle is
also noted. The power consumed by the individual VMs
in this setup is calculated as the difference in the power
consumed by the server when the VM is operational,
and the idle power consumption.
Chen et al. [8] provide an extensive discussion of
profiling the power consumption of VMs. The key
finding of their work is that when the vCPU is
mapped to threads on the physical CPU, as in case
of a cloud environment, the power consumption of
the VM follows the power consumption of the hosting
hardware. It is known that the kernel-based VM [47]
architecture spawns VMs as independent threads on the
hosting hardware. Hence, the power consumption of the
virtualized cloud increases linearly with an increase in
the workload running on the cloud instances. A similar
argument is provided for the memory subsystem. Power
consumption by a VM is considered to depend on the
actual physical resources utilized by the VM. See [8] for
details. Taking this key finding for a premise, we develop
the following power model for the cloud instances, based
on the resource utilization of the VM.
Now, to determine the power model for cloud instances,
let ui be the utilization of resource i of a cloud instance j.
A cloud instance is essentially a process (like KVM or
Xen) executing on a server. It follows from the above
where,
pj = power consumed by the cloud instance j in Watts,
Mi = measure of power consumption of resource i of
hosting machine full utilization (in Watts),
uj = utilization of resource i by cloud instance j, and
Ci = capacity of resource i on the hosting machine.
As the power consumption of the network and i/o
subsystems are negligible when compared to the power
consumed by the processor and memory subsystem [43],
these terms can be ignored from (6) without causing a
major error in the total power consumed. McCullough
et al. determine that the power consumption of the
processor subsystem accounts for 85% of the total
system power consumption and the memory subsystem
accounts for less than 10% of the total system power
consumption. Based on the findings in [43], we can
conclude that the power consumption of the memory
subsystem is close to 11% of that of the processor
subsystem. Hence for all practical purposes we can
consider the below equation to determine the power
consumed by the cloud instance.
ucpu umem
pj = Mcpu × + Mmem × (7)
Ccpu Cmem
or,  
ucpu
pj = 1.11 Mcpu × (8)
Ccpu
The equation (8) above represents the marginal
increment in the total power consumed by running the
instance j. This equation is used later to develop a cost
model of the data center hosting the cloud; specifically,
to calculate the total power consumed by the hosting
infrastructure (9).
4 E CONOMIC M ODEL
We establish the relation for cost of operation as a
function of the price of electricity specified by the
electricity service provider, the resource utilization, and
the base operational cost to keep the infrastructure
running. A pricing scheme and the bill generation
process are discussed in Section 4.2.
4.1 Cost Model
From (8) in the previous section, we determine the
power consumed by a cloud instance that is deployed.
The power consumption of the cloud hosting data
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
IEEE TRANSACTIONS ON SERVICES COMPUTING
Symbol Definition
Ct Total cost of running the cloud service at
time t
B Base cost of running the service
ξ Cost of power as indicated by the
electricity service provider
Pcloud Power consumed by cloud
p(j,t) Price of the cloud instance j at time t
C Total system resource capacity
φ Fixed price for utilizing the cloud
uj Resource utilization by cloud instance j
k, α Constants defined by the service
provider
TABLE 3
Symbols used in the economic model
center is the sum total of the power consumed by
all cloud instances and the power needed to keep the
infrastructure running. Hence, the total power consumed
is given by:  The price per cloud instance is defined by:
Pcloud = B + pj (9)
j p(j,t) = φ + k uj ×
The marginal cost of operation of one cloud instance is
then determined as a function of:
• the current cost of power as indicated by the
electricity service provider for a defined time
interval, ξ ($/kWh); and
• the base cost (B) incurred in running the service
(this includes software license costs, hardware
maintenance cost).
We define the cost of the cloud service at time t as:
Ct = B + ξ · Pcloud
where,
Ct = Total cost (in $) of running the cloud at time t
B = Base cost of the service,
ξ = Cost of electricity as specified by the power service
provider in $/kWh,
Pcloud = Power consumed by cloud in Watts.
We need to note that the cost of operation defined
above is variable due to amortization and increase in
the license refresh cost. However, in our work we do
not focus on these aspects and abstract these as B. The
cost of operation defined in (10) is used to calculate
the bill amount for the cloud instance hosted on the
infrastructure.
4.2 Pricing Scheme
Pricing for the cloud service can be applied based on
multiple considerations. Buyya et al. [48] list various
pricing considerations. Historically, flat-pricing models
and other simple proposals [49] were considered
8
for pricing Internet services. However, these are not
applicable in the current cloud scenario given variable
electricity costs.
Current service providers like Amazon [50] and
Rackspace [51] price cloud instances mostly based
on their configuration and duration of use. Another
prevalent practice is to charge consumers a fixed price
for a lease period like the Amazon reserved instance [50].
Assuming that we know the capacity of the hosting
infrastructure, we divide the base cost of service among
all the cloud instances that are hosted. This component
forms the fixed cost of using the cloud service by
consumer φ.
Our pricing model incorporates the following
parameters: (i) fixed cost of utilizing the cloud
service; (ii) an elastic cost which varies according
to the utilization; and (iii) balance factor cost which is
used to reduce the gap in the available resource and
actual resource demand.
  
Ct
− α(C − uj ) (11)
C j
where,
p(j,t) = price of the cloud instance j at time t (in $),
C = the total system resource capacity,
φ = fixed cost of utilizing the cloud
Ct = total cost of operation of the cloud service from (10)
uj = resource utilization by cloud instance j, and
k, α are constants defined by the service provider based
on the market economics. k is the scaling factor which
determines the marginal price of the cloud instance and
α is the penalty multiplier to ensure a balance between
(10) the utilized and available resource. Since we do not
cover the market economics of cloud services, we do not
include details on how to determine these constants.
The price per cloud instance (11) ensures the following:
1) The service provider is not burdened by the cost
of running the service in terms of license fee,
maintenance etc. This cost is split equally across
the deployed cloud instances and is captured in the
price per instance (φ).
2) When the resource utilization
 is low, the correction
factor recorded by (C − uj ) is high, hence the
price of the instance is reduced. This encourages
the consumers to avail the cloud service in terms of
number of instances or increased instance capacity.
3) When the resource utilization is high, the correction
factor is near zero, hence the price per instance is
the actual cost of operation. This being the case,
the consumers are discouraged to demand more
number instances and/or capacity.
4) The consumers are charged appropriately for the
resource utilization (via the instances owned by
them).
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
IEEE TRANSACTIONS ON SERVICES COMPUTING
9

The time of operation is divided into equal time intervals Algorithm 1: Resource Utilization Monitoring
called time slots for the purpose of sampling service output: vector instanceUtilizationData
utilization in the cloud infrastructure and the utilization 1 begin Instance Monitoring
by an individual consumer. The time slot granularity 2 while true do
is so defined that the price specification time of the 3 foreach Deployed Cloud Instance do
power grid is an integral multiple of the time slot 4 instanceUtilizationData ←
specified in the metering module. The other constraint RetrieveResourceUtilization(Instance)
to be considered while selecting the time slot is that 5 Store(instanceUtilizationData)
the amount of load generated on the system due to 6 end
monitoring is minimal. For instance, if T is the time 7 end
interval at which power prices are updated by the 8 end
electricity service provider, we can express the condition
above mathematically as, T = ρ · t, where ρ is some output: vector infrastructureUtilizationData
integer constant. 9 begin Infrastructure Monitoring
10 while true do
The billing amount is computed as a summation of the 11 foreach resource ∈ [cpu, memory, disk] do
instantaneous pricing obtained in (11) for each cloud 12 infrastructureUtilizationData ←
instance. The total bill amount for a cloud instance (j) RetrieveResourceUtilization(Server)
is obtained as:  13 Store(infrastructureUtilizationData)
Billj = p(j,t) (12) 14 end
t 15 end
where, p(j,t) is the operational price at time t for instance 16 end
j from (11). Data: vector
17 begin Store
18 save vector data in application database
5 I MPLEMENTATION 19 end

Resource monitoring of both the cloud instances
and the underlying hardware is necessary for the
metering mechanism described in the system model.
For the purpose of monitoring the resource utilization
of the cloud instances, we can use the hypervisor
counters provided by the various vendors like Microsoft
HyperV [52]. Standalone enterprise monitoring tools
like Hyperic SIGAR [53] can also be employed for
the purpose of resource usage monitoring of the cloud
instances. Any of the established enterprise data center
monitoring tools like Hyperic [54] or Nagios [55] can
be used to monitor the data center equipment resource
utilization.
Generation of billing information follows directly from
the cost model and the resource utilization. Once the
billing interval is specified, the number of time intervals
of operation is determined. For each such interval, the
bill amount is calculated as presented in the (11). The
total bill is then calculated as the summation of these
values.
Algorithm 1 depicts the resource utilization monitoring.
The two components of the algorithm are infrastructure
monitoring (lines 9–16) and deployed cloud instance
monitoring (lines 1–8) respectively. Since monitoring
is a continual operation, the process is represented in
the while block. Usage data are collected from either
the infrastructure components or the deployed cloud
instances (procedure listed in lines 20–22) and saved into
the application database (lines 17–19) for further use by
the prediction and bill calculation modules.
Data: Cloud instance or Physical server
output: vector
20 begin RetrieveResourceUtilization
21 utilizationData ← get utilization data from
performance counters or using an available tool
// this is a comment
return : utilizationData
22 end
Algorithm 2 details the calculation of the bill for
every cloud instance deployed. For the calculation of
an instance level bill, the stored resource utilization
of the particular cloud instance is retrieved from
the application database (lines 10–12). The power
consumption of an individual VMs is calculated using
(6). The instantaneous price for the instance is calculated
as per (11). For the given time interval (e.g., daily,
weekly or monthly), the total bill is calculated using
(12). The cost of operation of the cloud service is
calculated as in (10). This is internal to the calculation
of instantaneous price. The process of calculating the
bill amount is repeated for all instances deployed on the
cloud infrastructure (lines 2–8).
6 R ESULTS
For the purpose of testing the model proposed, a
Eucalyptus [56] cloud was set up on x86-64 based
machines running Ubuntu Linux. We used four Intel
i7 quad core machines for node servers and one Intel
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
IEEE TRANSACTIONS ON SERVICES COMPUTING
10

Algorithm 2: Billing Calculations

Data: vector utilizationData
Data: vector cloudInstances
Data: timeRange
1 begin CalculateBill
2 foreach interval in specified timeRange do
3 foreach cloud instance “j” in cloudInstances
do
4 utilizationData ←
RetrieveStoredUtilizationData(cloud
instance “j”)
5 compute power consumption of cloud
instance “j” as in (8)
6 calculate instantaneous price as given in (11) Fig. 3. Electricity cost input to the system (between
using the above 0800hrs and 1900hrs on 30 May 2012).
7 calculate total bill as given in (12)
8 end
return : bill
9 end
10 end

Data: Cloud instance

output: vector
11 begin RetrieveStoredUtilizationData
12 nextInstanceUtilizationData ← get stored
utilization data from application database
return : nextInstanceUtilizationData
13 end

Core2Duo machine for the cloud controller and storage
controller. Another dedicated Intel Core2Duo based
desktop machine was used as a client. A setup similar
to the schematic representation of cloud as shown in
Figure 1 was realized.
Standard Ubuntu images [57] were deployed on the
cloud instances. The resource utilization of the cloud
instances were recorded using off-the-shelf monitoring
tools like the Hyperic monitoring framework and
the Hyperic SIGAR framework. Cloud instances were
loaded using the Apache web server [58] and MySQL
database [59]. To induce additional load on the
infrastructure, artificial load generating processes were
introduced on the nodes. The configurations of the
load-generating processes were varied to change the
infrastructure utilization as desired.
As a part of the test, the input cost of electricity
was varied based on the data available from the
real-time electricity supply charges provided by PJM
Interconnection LLC [60]. Variation in the electricity cost
provided as input to the metering application is shown
in Figure 3. This graph corresponds to the electricity
cost from 0800 hrs to 1900 hrs on 30 May 2012. The
data collection interval was 10 minutes. These data were
obtained by PJM [60] for the Eastern Interconnection
Grid of the United States.
For purposes of evaluation, we deployed
Fig. 4. Utilization pattern of the workloads.
workloads on individual instances. We refer to
them as W L1, W L2, W L3 and W L4 in this work.
These workloads are representative of generic cloud
workload profiles: W L1 and W L3 are compute-intensive
workloads and reach peak utilization frequently, hence
their power consumption is also high (results are based
on the power model described in Section 3). However
W L2 and W L4 have low-moderate resource demand
mostly and have occasional spikes in the utilization.
Their power consumption also follows a similar pattern
as the resource utilization. The characteristics of the
workload are depicted in Figure 4.
A plot representing the overall system resource
utilization is shown in Figure 5. The straight line in
the graph indicates the cloud’s capacity. It was noted
during the evaluation that the responsiveness of the
infrastructure is within acceptable limits until the load
average reached a value of 3 per compute core. Hence
considering the cloud setup in our deployment had 16
cores, the cloud capacity is capped at 48. When the
utilization is beyond the capacity, a penalty price is
charged to the consumer and the corresponding price
for that peak period increases. This is captured while
calculating the instantaneous price in (11).
four The cost of operation represented in (10) tracks the
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
IEEE TRANSACTIONS ON SERVICES COMPUTING
Fig. 5. Overall system resource utilization.
Fig. 6. Variation of the cost of operation of cloud service
in accordance to the change in input cost of electricity.
input electricity cost. It also considers the total power
consumption of the infrastructure (Pcloud ). The variation
in cost of operation as per input electricity cost is shown
in Figure 6. It may be noted that the two curves in
the graph are at different scales. The cost of the input
electricity is represented in the continuous line and
the corresponding scale is the left-y-axis and the cost
of operation (represented by dotted lines) is according
to the scale on the right-y-axis. One may notice that
there are peaks in the cost of operation between 1040hrs
to 1120hrs. This is attributable to the peaks in the
power consumption during this time period (Figure 5).
Similarly the valleys in the cost of operation between
1500hrs to 1540hrs can be attributed to both the factors of
lower electricity cost and low cloud resource utilization.
It is interesting to note that between 1720hrs and 1740hrs,
even though there is a valley in the electricity cost, the
overall cost of operation has a peak, owing to the fact
that there was a peak in the cloud resource utilization
during the period.
Pricing for the cloud service was calculated as indicated
in (11). The result of the variations in service pricing
due to varying cost of electricity were recorded. This
is represented in Figure 7. The data range represented
in the graph is a snapshot of 11 hours duration from
11
Fig. 7. Variation of the service price in accordance to the
change in input cost of electricity and utilization.
the test period. It indicates the variation of the output
price for the duration of 11 hours corresponding to the
changes in the input cost of electricity. It is evident
that the price of cloud services increase as the resource
utilization increases.
 This follows from (11), where the
term α (C − uj ) is the balance factor. As utilization
j
increases, the balance factor reduces in (11) and the price
of service increases. Thus, increased power consumption
results in an increased price of the cloud service. Also it
can be noted that the balance factor significantly reduces
when the overall resource utilization of the infrastructure
is low. This reduces the service price thus encouraging
the consumers to avail additional instances or additional
resources.
The resource utilization of the cloud instances were
monitored and the bill generated as per (12). Based on
the resource utilization of the cloud instance and the total
utilization of infrastructure resources, a sample itemized
bill per running instance in the test setup was generated.
This bill captures the cloud instances in consideration,
their power utilization and the price to be paid by the
consumer who owns the cloud instances. The itemized
power consumption for four cloud workloads and the
billed price for each of them is listed in Table 4.
Cloud Power consumed Billed amount
instance (in KWh) (in Dollars)
W L1 3.21 65.76
W L2 0.71 15.05
W L3 2.99 60.79
W L4 1.04 22.92
TABLE 4
Itemized listing of power consumption & billed price on
the day of observation
There was a noticeable variation in the cloud instance
price in accordance with the resource utilization. This is
as per the expected behavior based on the cost model
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
IEEE TRANSACTIONS ON SERVICES COMPUTING
Fig. 9. Variation of price of the service for two workloads
using different power models.
and the pricing scheme proposed. As discussed earlier,
utilization directly affects the power consumption.
The cost of the cloud service varies with the power
consumption. The utilization data and the corresponding
price of the cloud service were calculated as per the
varying electricity cost. The graph in Figure 8 represents
the variation of price with utilization over a subset of
the entire test data.
Based on the tests performed, the following can be
inferred:
• As the input cost of electricity changes, the
cost of operation of the cloud service changes
correspondingly. Hence the price charged to the
consumer varies. The impact of a high utilization on
the infrastructure is directly observed in the output
price, i.e., the price levied on the customer.
• When the utilization of the infrastructure is below a
certain level as determined by the service provider,
there is a minimal price levied on the consumer. This
price accounts for the idle time of the infrastructure
as well as fixed and amortized costs. This follows
directly from (10) where a base operational cost is
accounted for.
• The system model described here provides for a
metering mechanism which is power-aware.
In order to compare the performance of the metering
mechanism described here, we used two different power
12
models [20], [42]. The motivation of this exercise was to
determine if the metering varies drastically with using
different power models for the infrastructure hosting the
cloud. We obtained a plot of the variation of price of the
infrastructure by holding the cost of electricity constant.
We applied the two different power models to individual
workloads for the same sets of utilization values logged.
The results of this experiment were not surprising. The
metering mechanism picked up the individual power
models and determined the price of the service. The
plots are shown in Figure 9. As can be seen in the plot,
the metering mechanism is independent of the power
model used. The advantage of this modularity is that,
our metering mechanism can be used with any power
model suitable to the cloud hosting environment.
7 C ONCLUSION
An effective relationship between input electricity cost,
cloud resource utilization, and individual utilization
of the cloud consumer is obtained in the proposed
model of power-aware cloud metering. Using this
relation, dynamic pricing of the cloud services based
on the utilization of the cloud infrastructure and input
electricity cost is achieved. Based on this dynamic
pricing information, a varying tariff model for the cloud
services is obtained in this work.
Specifically, the following goals are met in our work.
• Arrive at a power consumption model for the cloud
instances.
• Develop a cost model for cloud service which is
aligned with electricity pricing provided by a smart
grid.
• Track the price the cloud service based on the input
cost of electricity.
Our metering mechanism enables cloud computing
infrastructures to directly work with smart grids by
monitoring the power usage and helping the CIO enforce
policies to charge consumers appropriately for the power
consumed.
Our work thus has relevance in the context of
cloud services—especially infrastructure-as-a-service
(IaaS)—which need to operate in the presence of
dynamic electricity prices and new and forthcoming
smart grid technologies.
An analysis of the impact of dynamic pricing can be
performed to provide a comparison between the current
service pricing mechanisms and the dynamic pricing we
propose.
R EFERENCES
[1] L. A. Barroso, “The price of performance,” ACM Queue, vol. 3,
no. 7, pp. 48–53, Sep 2005.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
IEEE TRANSACTIONS ON SERVICES COMPUTING
Fig. 8. Variation of cloud service price in accordance with utilization and electricity price.
[2] P. M. Curtis, Maintaining Mission Critical Systems in a 24/7
Environment. Wiley-IEEE Press, 2007, ISBN 978-0471683742.
[3] K. Brill, Understanding the True Cost of
Operating a Server. facilitiesnet, Nov. 2008. [Online].
Available: http://www.facilitiesnet.com/datacenters/article/
Understanding-the-True-Cost-of-Operating-a-Server--10063
[4] L. Barroso and U. Holzle, “The case for energy-proportional
computing,” Computer, vol. 40, no. 12, pp. 33–37, Dec 2007, doi:
10.1109/MC.2007.443.
[5] C. Lefurgy, X. Wang, and M. Ware, “Server-level power control,”
in Fourth International Conference on Autonomic Computing (ICAC
2007). Los Alamitos, CA, USA: IEEE Computer Society, Jun. 2007.
[6] N. Singh and S. Rao, “Modeling and reducing power
consumption in large IT systems,” in 4th Annual IEEE International
Systems Conference (IEEE SysCon 2010), San Diego, CA, Apr. 2010,
pp. 178–183, doi:10.1109/SYSTEMS.2010.5482354.
[7] ——, “Energy optimization policies for server clusters,” in 6th
Annual IEEE Conference on Automation Science and Engineering
(IEEE CASE 2010), Toronto, Canada, Aug. 2010, pp. 293–300,
doi:10.1109/COASE.2010.5584153.
[8] Q. Chen, P. Grosso, K. van der Veldt, C. de Laat, R. Hofman,
and H. Bal, “Profiling energy consumption of vms for green
cloud computing,” in 2011 IEEE Ninth International Conference on
Dependable, Autonomic and Secure Computing (DASC), Dec. 2011,
pp. 768–775, doi: 10.1109/DASC.2011.131.
[9] A. Kansal, F. Zhao, J. Liu, N. Kothari, and A. A. Bhattacharya,
“Virtual machine power metering and provisioning,” in
Proceedings of the First ACM Symposium on Cloud Computing, ser.
SoCC ’10. ACM, 2010, pp. 39–50, doi: 10.1145/1807128.1807136.
[10] S. Bruno, S. Lamonaca, M. La Scala, G. Rotondo, and
U. Stecchi, “Load control through smart-metering on distribution
networks,” in 2009 IEEE PowerTech, July 2009, pp. 1–8, doi:
10.1109/PTC.2009.5282256.
[11] R. van Gerwen, S. Jaarsma, and R. Wilhite, “Smart metering,”
[Online], Available at http://www.leonardo-energy.org/webfm
send/435.
[12] “Global Data Center Energy Demand Forecasting,”
13
[Online], Tech. Rep., September 2011, available at:
http://www.datacenterdynamics.com/research.
[13] Y. Sverdlik, “Global data center energy use to grow by 19%
in 2012,” [Online], September 2011, available at: http://goo.gl/
5WnQP.
[14] “Global census shows datacentre power demand grew 63% in
2012,” [Online], available at: http://goo.gl/Sszpj.
[15] A. Verma, G. Dasgupta, T. K. Nayak, P. De, and R. Kothari, “Server
workload analysis for power minimization using consolidation,”
in Proceedings of the 2009 USENIX Annual Technical Conference, ser.
USENIX’09. USENIX Association, 2009, p. 28.
[16] M. Uddin and A. A. Rahman, “Server consolidation: An approach
to make data centers energy efficient and green,” CoRR, vol.
abs/1010.5037, 2010.
[17] D. Meisner, B. T. Gold, and T. F. Wenisch, “Powernap: Eliminating
server idle power,” SIGPLAN Not., vol. 44, no. 3, pp. 205–216, Mar.
2009, doi: 10.1145/1508284.1508269.
[18] A. Narayan, S. Rao, G. Ranjan, and K. Dheenadayalan, “Smart
metering of cloud services,” in 6th Annual IEEE International
Systems Conference (IEEE SysCon 2012), Vancouver, BC, Canada,
Mar. 2012, doi:10.1109/SysCon.2012.6189462.
[19] A. Qureshi, R. Weber, H. Balakrishnan, J. Guttag, and B. Maggs,
“Cutting the electric bill for internet-scale systems,” SIGCOMM
Comput. Commun. Rev., vol. 39, no. 4, pp. 123–134, Aug. 2009, doi:
10.1145/1594977.1592584.
[20] T. Heath, B. Diniz, E. V. Carrera, W. Meira, Jr., and R. Bianchini,
“Energy conservation in heterogeneous server clusters,” in
Proceedings of the Tenth ACM SIGPLAN Symposium on Principles
and Practice of Parallel Programming, ser. PPoPP ’05. ACM, 2005,
pp. 186–195, doi: 10.1145/1065944.1065969.
[21] M. Davison, C. Anderson, B. Marcus, and K. Anderson,
“Development of a hybrid model for electrical power spot prices,”
IEEE Trans. Power Syst., vol. 17, no. 2, pp. 257–264, May 2002.
[22] F. Alvarado and R. Rajaraman, “Understanding price volatility in
electricity markets,” in 2000. Proceedings of the 33rd Annual Hawaii
International Conference on System Sciences, Jan. 2000, p. 5 pp.
[23] N. Domingues, “Influence of the renewable energy in the
simulation of liberalised markets,” in Computational Sciences and
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
IEEE TRANSACTIONS ON SERVICES COMPUTING
Optimization, 2009. CSO 2009. International Joint Conference on,
vol. 2, April 2009, pp. 480 –484.
[24] Q. Zhao, P. Wang, Y. Ding, and L. Kumar Goel, “Impacts of
solar power penetration on nodal prices and nodal reliability,” in
IPEC, 2010 Conference Proceedings, Oct. 2010, pp. 1134–1139, doi:
10.1109/IPECON.2010.5696993.
[25] C. Lavania, S. Rao, and E. Subrahmanian, “Reducing
variation in solar energy supply through frequency domain
analysis,” IEEE Syst. J., vol. 6, no. 2, pp. 196–204, Jun. 2012,
doi:10.1109/JSYST.2011.2162796.
[26] W. Katzenstein, E. Fertig, and J. Apt, “The variability of
interconnected wind plants,” Energy Policy, vol. 38, no. 8, pp.
4400–4410, 2010, doi: 10.1016/j.enpol.2010.03.069.
[27] D. Hart, “Using ami to realize the smart grid,” in 2008 IEEE Power
and Energy Society General Meeting - Conversion and Delivery of
Electrical Energy in the 21st Century, July 2008, pp. 1–2.
[28] “Assessment of demand response and advanced metering,”
Federal Energy Regulatory Committee, Tech. Rep.
[Online]. Available: http://www.ferc.gov/legal/staff-reports/
2010-dr-report.pdf
[29] H.-P. Siderius and A. Dijkstra, “Smart metering for households:
Cost and benefits for the Netherlands,” EEDAL, 2006.
[30] J. W. Ross, M. R. Vitale, and C. M. Beath, “The untapped potential
of it chargeback,” MIS Quarterly, vol. 23, no. 2, pp. 215–237, June
1999.
[31] R. Iyer, R. Illikkal, L. Zhao, D. Newell, and J. Moses, “Virtual
platform architectures for resource metering in datacenters,”
SIGMETRICS Perform. Eval. Rev., vol. 37, pp. 89–90, October 2009.
[32] “Amazon spot instance,” [Online], Available at http://aws.
amazon.com/ec2/spot-instances/.
[33] T. Singh and P. K. Vara, “Smart metering the clouds,” in 18th
IEEE International Workshops on Enabling Technologies: Infrastructure
for Collaborative Enterprises (WETICE 2009), 2009, pp. 66–71,
doi:10.1109/WETICE.2009.49.
[34] A. H. Mohsenian-Rad and A. Leon-Garcia, “Optimal residential
load control with price prediction in real-time electricity pricing
environments,” Smart Grid, IEEE Transactions on, vol. 1, no. 2, pp.
120–133, September 2010, doi: 10.1109/TSG.2010.2055903.
[35] J. Rao and C.-Z. Xu, “Online capacity identification of
multitier websites using hardware performance counters,” IEEE
Trans. Parallel Distrib. Syst., vol. 22, pp. 426–438, 2011, doi:
10.1109/TPDS.2010.92.
[36] C. Lefurgy, K. Rajamani, F. Rawson, W. Felter, M. Kistler, and T. W.
Keller, “Energy management for commercial servers,” Computer,
vol. 36, pp. 39–48, 2003, doi: 10.1109/MC.2003.1250880.
[37] R. Bianchini and R. Rajamony, “Power and energy management
for server systems,” Computer, vol. 37, pp. 68–74, 2004, doi:
10.1109/MC.2004.217.
[38] P. Ranganathan, P. Leech, D. Irwin, and J. Chase, “Ensemble-level
power management for dense blade servers,” SIGARCH Comput.
Archit. News, vol. 34, no. 2, pp. 66–77, May 2006, doi:
10.1145/1150019.1136492.
[39] Q. Deng, D. Meisner, L. Ramos, T. F. Wenisch, and R. Bianchini,
“Memscale: active low-power modes for main memory,”
SIGARCH Comput. Archit. News, vol. 39, no. 1, pp. 225–238, Mar.
2011, doi: 10.1145/1961295.1950392.
[40] J. Choi, S. Govindan, J. Jeong, B. Urgaonkar, and
A. Sivasubramaniam, “Power consumption prediction and
power-aware packing in consolidated environments,” IEEE Trans.
Comput., vol. 59, pp. 1640–1654, 2010, doi: 10.1109/TC.2010.91.
[41] J.-W. Jang, M. Jeon, H.-S. Kim, H. Jo, J.-S. Kim, and
S. Maeng, “Energy reduction in consolidated servers through
memory-aware virtual machine scheduling,” IEEE Trans. Comput.,
vol. 60, pp. 552–564, 2011, doi: 10.1109/TC.2010.82.
[42] D. Economou, S. Rivoire, and C. Kozyrakis, “Full-system power
analysis and modeling for server environments,” in In Workshop
on Modeling Benchmarking and Simulation (MOBS), 2006.
[43] J. C. McCullough, Y. Agarwal, J. Chandrashekar, S. Kuppuswamy,
A. C. Snoeren, and R. K. Gupta, “Evaluating the effectiveness of
model-based power characterization,” in Proceedings of the 2011
USENIX conference on USENIX annual technical conference, ser.
USENIXATC’11. USENIX Association, 2011, pp. 12–12.
[44] B. Krishnan, H. Amur, A. Gavrilovska, and K. Schwan,
“Vm power metering: Feasibility and challenges,” SIGMETRICS
Perform. Eval. Rev., vol. 38, no. 3, pp. 56–60, Jan. 2011, doi:
10.1145/1925019.1925031.
14
[45] D. C. Snowdon, S. M. Petters, and G. Heiser, “Accurate on-line
prediction of processor and memory energy usage under voltage
scaling,” in Proceedings of the 7th ACM & IEEE International
Conference on Embedded Software, ser. EMSOFT ’07. ACM, 2007,
pp. 84–93, doi: 10.1145/1289927.1289945.
[46] W. Bircher and L. John, “Complete system power estimation using
processor performance events,” IEEE Trans. Comput., vol. 61, no. 4,
pp. 563–577, April 2012, doi: 10.1109/TC.2011.47.
[47] A. Kivity, Y. Kamay, D. Laor, U. Lublin, and A. Liguori, “kvm:
the linux virtual machine monitor,” Online, Tech. Rep., 2007,
available at https://www.kernel.org/doc/mirror/ols2007v1.pdf#
page=225.
[48] R. Buyya, D. Abramson, and J. Giddy, “A case for economy grid
architecture for service oriented grid computing,” International
Parallel and Distributed Processing Symposium, vol. 2, 2001.
[49] L. McKnight and J. Boroumand, “Pricing internet services:
proposed improvements,” Computer, vol. 33, no. 3, pp. 108–109,
March 2000.
[50] “Amazon pricing,” [Online], Available at http://aws.amazon.
com/ec2/pricing/.
[51] “Rackspace pricing,” [Online], Available at http://www.
rackspace.com/cloud/cloud hosting products/servers/
pricing/.
[52] “Hypervisor statistics counter definition,” [Online], Available
at http://msdn.microsoft.com/en-us/library/windows/
hardware/ff541603\%28v=vs.85\%29.aspx.
[53] “Hyperic sigar api,” [Online], Available at http://www.hyperic.
com/products/sigar.
[54] “Hyperic opensource monitoring,” [Online], Available at http://
www.hyperic.com/products/open-source-systems-monitoring.
[55] “Nagios,” [Online], Available at http://www.nagios.org/.
[56] “Open eucalyptus,” [Online], Available at http://open.
eucalyptus.com/.
[57] “Ubuntu cloud images,” [Online], Available at http:
//uec-images.ubuntu.com/.
[58] “Apache HTTP server,” [Online], Available at http://httpd.
apache.org/.
[59] “MySQL open source database server,” [Online], Available at
http://www.mysql.com/.
[60] “Pjm interconnection llc,” [Online], Available at https://edata.
pjm.com/eData/index.html.
Akshay Narayan completed his MTech in
information technology from IIIT-Bangalore
and currently pursuing his Ph.D in School of
Computing, National University of Singapore.
PLACE He is currently working on sequential decision
PHOTO
making. His research interests include artificial
HERE intelligence and its application in cloud
computing.
Shrisha Rao received his Ph.D. in computer
science from the University of Iowa, and before
that his M.S. in logic and computation from
Carnegie Mellon University. He is an associate
PLACE professor at IIIT-Bangalore, a graduate school of
PHOTO information technology in Bangalore, India. His
HERE research interests are in distributed computing,
specifically algorithms and approaches for
concurrent and distributed systems, and include
solar energy and microgrids, cloud computing,
energy-aware computing (”green IT”), and
demand side resource management. Dr. Rao is a member of the IEEE
Computer Society, the ACM, the American Mathematical Society, and
the Computer Society of India.