Subject: Re: [eman] Time series of power measurements

From: Jorge Ortiz <[email-masked]>
Date: Thu, 9 Feb 2012 12:11:23 +0900

All,

Getting into the specifics of timeseries measurement logging can easily get
a bit complicated.  My concern in recommending a mechanism is
distinguishing between three  underlying frequencies implied when a
measurement is taken: the frequency of the underlying phenomenon, the
sampling frequency, and the report frequency.  Without this distinction, it
will be difficult to ensure accuracy in the total power-consumption measure.

Another concern is that energy consumed in a monotonically increasing, so
we will run into wrap-out issues.  That said, Bruce mentioned an averaging
window size should be included in the report.  This would be useful for
minimizing value wrap-around.

Time synchronization is important, but it really depends on the measurement
report latency and the underlying frequency of the phenomenon.  If the
thing being measured changes slowly, then synchronization will not matter
as much as long as readings lie within a reasonable time window.  If it
changes quickly, we'll probably want summary statistics anyway and a window
over which those statistics were calculated.

Best,

Jorge

---

From: Daniel Kharitonov <[email-masked]>
Date: Wed, 8 Feb 2012 21:25:32 -0800

Jorge,

Please see below.

> the frequency of the underlying phenomenon

I don't think the consumption of energy has underlying frequency, at least until the quantum-level resolution is reached )

> the sampling frequency

This is a function of integrated PSU sensors. Typically ranges in Khz. 
However, the operating system itself does not poll the registers that often; it is more common to have a counter that is updated every 1-10 seconds or so.

> and the report frequency.  Without this distinction, it will be difficult to ensure accuracy in the total power-consumption measure.

I would agree with Bruce that time aggregates are mostly a convenience feature.

While every device will have it's own minimal update resolution, those figures are quite low and not interesting for energy savings estimates.
Average 1 min / 5 min/30 min/1hr/24 hr intervals can be more useful for billing and management purposes.

Another concern is that energy consumed in a monotonically increasing, so we will run into wrap-out issues.  That said, Bruce mentioned an averaging window size should be included in the report.  This would be useful for minimizing value wrap-around.

> If the thing being measured changes slowly, then synchronization will not matter as much as long as readings lie within a reasonable time window.  

Alternatively, with reasonable convenience intervals it may not matter at all.

For the energy management NMS the consumption peaks due to fan on/off or similar events are not very interesting. It is more interesting to learn a broader energy use over 1hr-24hr interval with certain power states activated. 

However, please bear in mind that when designing an energy NMS it is very important to know traffic parameters with resolution and error counters good enough to approximate usage pattern with power states.

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Thu, 9 Feb 2012 06:46:50 -0600

Hello Bruce and Jorge,

Regarding the Time Series of Power and Energy measurements, there was a
lot of discussion at IETF82 meeting, expressing the need for this. 

Fundamentally, the issue addressed is that if the time between
successive polling of a same device is too long, which can happen in a
large network. 

In that setting,  between the long polling cycles, some of power peaks
can be lost.  

So, it was suggested that it would be useful to store a small time
series of power measurements at a device. 

The mechanism for reporting the time series can be based on push or
pull.  

Jorge, 

Your point is well taken.  

Presently, the MIB module   -
http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-01
reports the underlying frequency is of Alternating current and internal
sampling rate of power and the aggregating window (fixed period, sliding
window, ...).  

Based on the revised requirements for time series reporting and the
mechanisms,  additional parameters to report can be considered.  

Thanks

Mouli

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jorge Ortiz
Sent: Thursday, February 09, 2012 8:41 AM
To: [email-masked]
Subject: Re: [eman] Time series of power measurements

All,

Getting into the specifics of timeseries measurement logging can easily
get a bit complicated.  My concern in recommending a mechanism is
distinguishing between three  underlying frequencies implied when a
measurement is taken: the frequency of the underlying phenomenon, the
sampling frequency, and the report frequency.  Without this distinction,
it will be difficult to ensure accuracy in the total power-consumption
measure.

Another concern is that energy consumed in a monotonically increasing,
so we will run into wrap-out issues.  That said, Bruce mentioned an
averaging window size should be included in the report.  This would be
useful for minimizing value wrap-around.

Time synchronization is important, but it really depends on the
measurement report latency and the underlying frequency of the
phenomenon.  If the thing being measured changes slowly, then
synchronization will not matter as much as long as readings lie within a
reasonable time window.  If it changes quickly, we'll probably want
summary statistics anyway and a window over which those statistics were
calculated.

Best,

Jorge

---

From: Jorge Ortiz <[email-masked]>
Date: Thu, 9 Feb 2012 22:04:01 +0900

Daniel,

On Thu, Feb 9, 2012 at 2:25 PM, Daniel Kharitonov <[email-masked]> wrote:

> I don't think the consumption of energy has underlying frequency, at least
> until the quantum-level resolution is reached )
>

The power-draw characteristics certainly does have a set of underlying
combination of frequencies.  Doing any signal analysis on a typical power
trace will show it.  The power trace of a laptop, for example, is quite
different from the power trace for a lamp.

> However, the operating system itself does not poll the registers that
> often; it is more common to have a counter that is updated every 1-10
> seconds or so.
>

Seems reasonable.

>
> > and the report frequency.  Without this distinction, it will be
> difficult to ensure accuracy in the total power-consumption measure.
>

Sure.  Where the aggregate is computed is not as important if timestamped
power readings are recorded, since the aggregate can be computed from the
traces.

>
> While every device will have it's own minimal update resolution, those
> figures are quite low and not interesting for energy savings estimates.
> > If the thing being measured changes slowly, then synchronization will
> not matter as much as long as readings lie within a reasonable time window.
>
> For the energy management NMS the consumption peaks due to fan on/off or
> similar events are not very interesting. It is more interesting to learn a
> broader energy use over 1hr-24hr interval with certain power states
> activated.
>
> However, please bear in mind that when designing an energy NMS it is very
> important to know traffic parameters with resolution and error counters
> good enough to approximate usage pattern with power states.

---

From: Daniel Kharitonov <[email-masked]>
Date: Thu, 9 Feb 2012 11:11:14 -0800

Hi Jorge,

DK> I don't think the consumption of energy has underlying frequency, at least until the quantum-level resolution is reached )
JO> The power-draw characteristics certainly does have a set of underlying combination of frequencies.  Doing any signal analysis on a typical power trace will show it.  The power trace of a laptop, for example, is quite different from the power trace for a lamp.

I don't think we made a statement that an ICT device has a flat energy footprint profile.
However, the details of that complex aperiodic process are less interesting to us relative to consumption at intervals meaningful to billing.

Therefore, we do not have to solve the Nyquist–Shannon problem here and try to collect samples with frequency above the certain system-specific limit.
In fact, whatever we do is already reduced to resolution of several seconds per sample at the best.

What is likely *more* interesting to us is the behavior of useful payload in the same period.
This is related to fact that we can only change power states if we are sure the certain minimal QoS agreements are reached.

---------------------------------

Seems reasonable.

Sure.  Where the aggregate is computed is not as important if timestamped power readings are recorded, since the aggregate can be computed from the traces.

---

From: Jorge Ortiz <[email-masked]>
Date: Fri, 10 Feb 2012 07:38:58 +0900

On Fri, Feb 10, 2012 at 4:11 AM, Daniel Kharitonov <[email-masked]> wrote:

> Hi Jorge,
>
>
> DK> I don't think the consumption of energy has underlying frequency, at
> least until the quantum-level resolution is reached )
> JO> The power-draw characteristics certainly does have a set of underlying
> However, the details of that complex aperiodic process are less
> interesting to us relative to consumption at intervals meaningful to
> billing.
>

I see.  That's a fair point.  My main concern was that we don't miss too
many peaks so that it impacts our assessment of the total energy consumed
over extended periods.

>
> Therefore, we do not have to solve the Nyquist–Shannon problem here and
> try to collect samples with frequency above the certain system-specific
> limit.
> This is related to fact that we can only change power states if we are
> sure the certain minimal QoS agreements are reached.
>

Can you elaborate a bit more on this point?

---

From: Daniel Kharitonov <[email-masked]>
Date: Thu, 9 Feb 2012 15:09:47 -0800

Hi Jorge,

JO> My main concern was that we don't miss too many peaks so that it impacts our assessment of the total energy consumed

This is a valid argument that justifies a cumulative counter on the device itself (or an array of such counters rolling at different intervals).

Practically, we cannot expect NMS to pull instantaneous snapshots too often. However, it is easy to pull summary counters once every hour or once every day.

DK> What is likely *more* interesting to us is the behavior of useful payload in the same period.
JO> Can you elaborate a bit more on this point?

This point becomes relevant when we think about active power state management in the large ICT domain.

Power-managing real-time systems like transit network devices (RAN, routers, switches, DSLAMs) is inherently difficult because if they transcend into wrong power states, traffic will be irreversibly lost.

To plan and assess the situation, NMS personnel needs to know both historical and current utilization trends along with statistics for unexpected traffic loss.

As an example, let's look at day of life of a switch in the Enterprise.

In the daytime, traffic patterns are rarely predictable as any user can transfer data anytime. Therefore, the switch remains at 100 percent capacity and energy mgmt (if any) needs to happen in realtime (e.g. 802.3az or similar).

At night, the switch can be moved into a lower power states that possibly trade energy for capacity or other service characteristics.

Now the question - if we have a series of available states (say, 50, 30 and 10 percent capacity on a device), what is the right one to choose?

To know this, we must have collected this data before to validate the possibility of transition. Here, the resolution is critical because data peaks can be very shortlived.

Moreover, data peaks may still happen when switch operates in reduced power state. We need mechanisms to detect overload and report this back to NMS to ensure we back off to more capacity should we made a wrong judgement.

From: Jorge Ortiz [mailto:[email-masked]]
Sent: Thursday, February 09, 2012 02:38 PM
To: Daniel Kharitonov
Cc: [email-masked] <[email-masked]>
Subject: Re: [eman] Time series of power measurements

On Fri, Feb 10, 2012 at 4:11 AM, Daniel Kharitonov <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jorge,

I see.  That's a fair point.  My main concern was that we don't miss too many peaks so that it impacts our assessment of the total energy consumed over extended periods.

Seems reasonable.

---

From: Bruce Nordman <[email-masked]>
Date: Thu, 9 Feb 2012 15:38:59 -0800

I want to express a concern that the title of this thread is “time series
of power measurements” – in my work with energy use and efficiency, time
series data are always energy measurements.  These can be expressed as
average power over each period of course, but these are derived – the basic
data are energy.

Mouli, in his original message, noted that the current requirements draft
speaks to both time series of power and time series of energy.  I suggest
that we need only the energy time series.  A power time series would be
just a periodic snapshot of current power and not give visibility into what
happened in between.  An EMS should simply request an interval appropriate
to its needs.  In his second post, Mouli notes that “between long cycles,
some … power peaks can be lost”.  Peaks will not be lost in energy
measures, but would be in power measures, which is why energy is so much
more useful.  The ODVA documents refer to energy “odometers” – which
applies to energy but not power – so they are thinking along the same lines.

So, I propose that the drafts incorporate the following conclusions:

--Time series of energy only

--Adopt the principle that the time series data should be the same as the
result if they were polled individually at the time stamps reported

--Only support a single duration/synch set.  How many time periods can be
reported is up to the device – from zero to a  large number.

Bruce

(as contributor)

On Thu, Feb 9, 2012 at 3:09 PM, Daniel Kharitonov <[email-masked]> wrote:

>
> Hi Jorge,
>
> JO> My main concern was that we don't miss too many peaks so that it
> impacts our assessment of the total energy consumed
>
> This is a valid argument that justifies a cumulative counter on the device
> itself (or an array of such counters rolling at different intervals).
>
> Practically, we cannot expect NMS to pull instantaneous snapshots too
> often. However, it is easy to pull summary counters once every hour or once
> every day.
>
> Power-managing real-time systems like transit network devices (RAN,
> routers, switches, DSLAMs) is inherently difficult because if they
> transcend into wrong power states, traffic will be irreversibly lost.
>
> To plan and assess the situation, NMS personnel needs to know both
> historical and current utilization trends along with statistics for
> unexpected traffic loss.
>
> In the daytime, traffic patterns are rarely predictable as any user can
> transfer data anytime. Therefore, the switch remains at 100 percent
> capacity and energy mgmt (if any) needs to happen in realtime (e.g. 802.3az
> or similar).
>
> At night, the switch can be moved into a lower power states that possibly
> trade energy for capacity or other service characteristics.
>
> Now the question - if we have a series of available states (say, 50, 30
> and 10 percent capacity on a device), what is the right one to choose?
>
> To know this, we must have collected this data before to validate the
> possibility of transition. Here, the resolution is critical because data
> peaks can be very shortlived.
>
> Moreover, data peaks may still happen when switch operates in reduced
> power state. We need mechanisms to detect overload and report this back to
> NMS to ensure we back off to more capacity should we made a wrong judgement.
>
>
>
>
>
>
>
>  *From*: Jorge Ortiz [mailto:[email-masked]]
> *Sent*: Thursday, February 09, 2012 02:38 PM
> *To*: Daniel Kharitonov
> *Cc*: [email-masked] <[email-masked]>
> *Subject*: Re: [eman] Time series of power measurements
>
>
>
> On Fri, Feb 10, 2012 at 4:11 AM, Daniel Kharitonov <[email-masked]>wrote:
>
>> Hi Jorge,
>>
>>
>> JO> The power-draw characteristics certainly does have a set of
>> underlying combination of frequencies.  Doing any signal analysis on a
>> typical power trace will show it.  The power trace of a laptop, for
>> example, is quite different from the power trace for a lamp.
>>
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman
>
>

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
[email-masked]
510-486-7089
m: 510-501-7943

---

From: "John Parello (jparello)" <[email-masked]>
Date: Thu, 9 Feb 2012 16:54:57 -0800

Not expressing an opinion either way but I just want to make it clear for the discussion.

At the ODVA we used the analogy of power=speed and energy=distance.

So here’s two series of power and energy readings (BTW Both series of readings misses spikes in the intervals.)

Interval    Power   Energy

0                0W         0kwh

1            100W    500kwh

2            120W    600kwh

3            200W   1000kwh

4            150W   1350kwh

5            100W   1500kwh

Are we saying that the power series (speed) is not useful and only the energy series (distance) is useful?

What about devices that cannot implement  energy and can only report their power ?

What about devices that can only report their power based on estimates and cannot report energy, do you exclude them from time series data then as well?

Jp

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bruce Nordman
Sent: Thursday, February 09, 2012 3:39 PM
To: Daniel Kharitonov
Cc: [email-masked]; [email-masked]
Subject: Re: [eman] Time series of power measurements

I want to express a concern that the title of this thread is “time series of power measurements” – in my work with energy use and efficiency, time series data are always energy measurements.  These can be expressed as average power over each period of course, but these are derived – the basic data are energy.

Mouli, in his original message, noted that the current requirements draft speaks to both time series of power and time series of energy.  I suggest that we need only the energy time series.  A power time series would be just a periodic snapshot of current power and not give visibility into what happened in between.  An EMS should simply request an interval appropriate to its needs.  In his second post, Mouli notes that “between long cycles, some … power peaks can be lost”.  Peaks will not be lost in energy measures, but would be in power measures, which is why energy is so much more useful.  The ODVA documents refer to energy “odometers” – which applies to energy but not power – so they are thinking along the same lines.

--Adopt the principle that the time series data should be the same as the result if they were polled individually at the time stamps reported

--Only support a single duration/synch set.  How many time periods can be reported is up to the device – from zero to a  large number.

Bruce

(as contributor)

Hi Jorge,

 

 

Hi Jorge,

	

 

	

	
	Seems reasonable.

	

	

	

-- 
Bruce Nordman

---

From: Jorge Ortiz <[email-masked]>
Date: Fri, 10 Feb 2012 14:08:31 +0900

Daniel,

Thanks for elaborating.  Part of my initial confusion is terminology and
statement of goals.  The driving goal here is to use the timeseries energy
data to improve capacity planning -- both static and dynamic.

>From this falls out the question: where data collection and processing
should take place to maintain good accuracy on our view of energy
consumption.  Some sub-questions fall out from there:

1)  What data should be collected by the meter?
2)  What processing should the meter do with the collected data?
3)  What service should the meter provide to consumers?

The answer to these questions is fundamentally driven by the goal.  Now,
this is quite complicated in the networking sense because the demand and
QoS requirements dictate the resources allocated.  Furthermore, we want to
provide a general solution, so we can support a wide range of applications.

Providing energy statistics is useful, as the underlying metered sampling
rate is probably high enough to capture transitions in power-draw (i.e.
fast enough to capture the peaks and valleys), however, it's too fast to be
reported.  The natural solution here, then, is to compute summarizing
statistics that integrate power over time, over a pre-defined time window.
 That answers the first 2 questions.  Power data should be collected
locally and it should be accumulated in a register over a moving time
interval.

Now, to address the service(s) provided we have to keep in mind the
applications we want to build.  Going back to the goal, we want to do
static and dynamic provisioning.  To do this we need energy consumed over
time, I presume.  If that is indeed the case, then perhaps we can define a
service specification for obtaining the last energy window calculation.  We
can extend the service to report the value each time it is changed.

Jorge

---

From: Jorge Ortiz <[email-masked]>
Date: Fri, 10 Feb 2012 14:11:42 +0900

> average power over each period of course, but these are derived – the basic

Assuming we are measuring power and integrating over time, then energy
reporting should be the service abstraction provided.

> happened in between.  An EMS should simply request an interval
> appropriate to its needs.  In his second post, Mouli notes that “between
> long cycles, some … power peaks can be lost”.  Peaks will not be lost in
> energy measures, but would be in power measures, which is why energy is so
> much more useful.  The ODVA documents refer to energy “odometers” – which

Perhaps as part of the service specification, we can also provide
instantaneous power readings, of the last measured power level.

Jorge

>> This is a valid argument that justifies a cumulative counter on the
>> device itself (or an array of such counters rolling at different intervals).
>>
>>> Sure.  Where the aggregate is computed is not as important if
>>> timestamped power readings are recorded, since the aggregate can be
>>> computed from the traces.
>>>
>>>
>>> However, please bear in mind that when designing an energy NMS it is
>>> very important to know traffic parameters with resolution and error
>>> counters good enough to approximate usage pattern with power states.
>>>
>>
>>

---

From: Jorge Ortiz <[email-masked]>
Date: Fri, 10 Feb 2012 14:15:00 +0900

Hi John,

On Fri, Feb 10, 2012 at 9:54 AM, John Parello (jparello) <[email-masked]
> wrote:

> Not expressing an opinion either way but I just want to make it clear for
> the discussion.****
>
> ** **
>
> At the ODVA we used the analogy of power=speed and energy=distance.****
>
> ** **
>
> So here’s two series of power and energy readings (BTW Both series of
> readings misses spikes in the intervals.)
>
****
>
> ** **
>
> ** **
>
> Interval    Power   Energy****
>
> 0                0W         0kwh****
>
> 1            100W    500kwh****
>
> 2            120W    600kwh****
>
> 3            200W   1000kwh****
>
> 4            150W   1350kwh****
>
> 5            100W   1500kwh****
>
> ** **
>

That's the claim, yes.  Instantaneous power readings may miss peaks/valleys
unless the sampling rate is high enough.

> ****
> ** **

That's a good point.  However, I still think local energy calculations
should be made at the meter if possible.  If it's already collecting power
data, it might as well integrate over time.

> ****
>
> What about devices that can only report their power based on estimates and
> cannot report energy, do you exclude them from time series data then as
> well?
>

That's actually why I think there should be an instantaneous power
reporting service; to handle such cases.

Jorge

> ****
>
> ** **
>
> Jp****
>
> ** **
>
> ** **
>
> ** **
>
> ****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Bruce Nordman
> *Sent:* Thursday, February 09, 2012 3:39 PM
> *To:* Daniel Kharitonov
> *Cc:* [email-masked]; [email-masked]
>
> *Subject:* Re: [eman] Time series of power measurements****
>
> ** **
>
> data are energy.****
>  ****
> ****
>  ****
> So, I propose that the drafts incorporate the following conclusions:****
>
> --Time series of energy only****
>
> result if they were polled individually at the time stamps reported****
>
> reported is up to the device – from zero to a  large number.****
>
> ** **
>
> Bruce****
>
> (as contributor)****
>
> ** **
>
> ****
>  ****
> *Cc*: [email-masked] <[email-masked]> ****
>
> *Subject*: Re: [eman] Time series of power measurements ****
>
>  ****
>
> ** **
>
> ** **
>
> On Fri, Feb 10, 2012 at 4:11 AM, Daniel Kharitonov <[email-masked]>
> wrote:****
>
> Hi Jorge,
>
>
> billing.****
> ** **
> over extended periods.****
>
>  ****
>
>
> sure the certain minimal QoS agreements are reached.****
>
> ** **
>
> Can you elaborate a bit more on this point? ****
>
> ** **
>
> ** **
>
>
>
>
> ---------------------------------****
>
>
> > the sampling frequency
>
> good enough to approximate usage pattern with power states.****
>
> ** **
>
>
> https://www.ietf.org/mailman/listinfo/eman****
>
>
>
>
> --
> *Bruce Nordman*
> m: 510-501-7943****

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Fri, 10 Feb 2012 01:23:22 -0600

Glad to  see that we are hashing this out. 

Replies inline. 

Thanks

Mouli

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jorge Ortiz
Sent: Friday, February 10, 2012 10:45 AM
To: John Parello (jparello)
Cc: [email-masked]
Subject: Re: [eman] Time series of power measurements

	Are we saying that the power series (speed) is not useful and
only the energy series (distance) is useful?

That's the claim, yes.  Instantaneous power readings may miss
peaks/valleys unless the sampling rate is high enough.

YCM>>>   I am presuming this is one of definition of how the measurement
is done.  

YCM>>>  To clarify,  Power measurement is not an instantaneous
measurement.  For AC, this measurement is obtained as an average of a
fixed number of sinusoidal cycles. 

YCM>>>  We have power measurements of devices of as requirement. In
addition, there is also a requirement to collect energy measurement of
devices. 

YCM>>>  The question is - should we have time series of power (such
averaged measurements) stored at a device and then retrieved or pushed
to the NMS. 

YCM>>> At the WG, there was a consensus, there should be requirements to
have time series of both power and energy measurements. 

YCM>>> It should be noted that the requirements concern the standards
specification and not the implementations of specific standards. 

	What about devices that cannot implement  energy and can only
report their power ?

That's a good point.  However, I still think local energy calculations
should be made at the meter if possible.  If it's already collecting
power data, it might as well integrate over time.

	What about devices that can only report their power based on
estimates and cannot report energy, do you exclude them from time series
data then as well?

Jorge

	Jp

	 

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bruce Nordman
	Sent: Thursday, February 09, 2012 3:39 PM
	To: Daniel Kharitonov
	Cc: [email-masked]; [email-masked]

	I want to express a concern that the title of this thread is
"time series of power measurements" - in my work with energy use and
efficiency, time series data are always energy measurements.  These can
be expressed as average power over each period of course, but these are
derived - the basic data are energy.

	Mouli, in his original message, noted that the current
requirements draft speaks to both time series of power and time series
of energy.  I suggest that we need only the energy time series.  A power
time series would be just a periodic snapshot of current power and not
give visibility into what happened in between.  An EMS should simply
request an interval appropriate to its needs.  In his second post, Mouli
notes that "between long cycles, some ... power peaks can be lost".
Peaks will not be lost in energy measures, but would be in power
measures, which is why energy is so much more useful.  The ODVA
documents refer to energy "odometers" - which applies to energy but not
power - so they are thinking along the same lines.

	So, I propose that the drafts incorporate the following
conclusions:

	--Adopt the principle that the time series data should be the
same as the result if they were polled individually at the time stamps
reported

	--Only support a single duration/synch set.  How many time
periods can be reported is up to the device - from zero to a  large
number.

	Bruce

	(as contributor)

	On Thu, Feb 9, 2012 at 3:09 PM, Daniel Kharitonov
<[email-masked]> wrote:

	Hi Jorge,
	
	JO> My main concern was that we don't miss too many peaks so
that it impacts our assessment of the total energy consumed 
	
	This is a valid argument that justifies a cumulative counter on
the device itself (or an array of such counters rolling at different
intervals).
	
	Practically, we cannot expect NMS to pull instantaneous
snapshots too often. However, it is easy to pull summary counters once
every hour or once every day.
	
	DK> What is likely *more* interesting to us is the behavior of
useful payload in the same period.
	JO> Can you elaborate a bit more on this point? 
	
	This point becomes relevant when we think about active power
state management in the large ICT domain.
	
	Power-managing real-time systems like transit network devices
(RAN, routers, switches, DSLAMs) is inherently difficult because if they
transcend into wrong power states, traffic will be irreversibly lost.
	
	To plan and assess the situation, NMS personnel needs to know
both historical and current utilization trends along with statistics for
unexpected traffic loss.
	
	As an example, let's look at day of life of a switch in the
Enterprise.
	
	In the daytime, traffic patterns are rarely predictable as any
user can transfer data anytime. Therefore, the switch remains at 100
percent capacity and energy mgmt (if any) needs to happen in realtime
(e.g. 802.3az or similar).
	
	At night, the switch can be moved into a lower power states that
possibly trade energy for capacity or other service characteristics.
	
	Now the question - if we have a series of available states (say,
50, 30 and 10 percent capacity on a device), what is the right one to
choose?
	
	To know this, we must have collected this data before to
validate the possibility of transition. Here, the resolution is critical
because data peaks can be very shortlived.
	
	Moreover, data peaks may still happen when switch operates in
reduced power state. We need mechanisms to detect overload and report
this back to NMS to ensure we back off to more capacity should we made a
wrong judgement.

	

	 

	On Fri, Feb 10, 2012 at 4:11 AM, Daniel Kharitonov
<[email-masked]> wrote:

	Hi Jorge,

	DK> I don't think the consumption of energy has underlying
frequency, at least until the quantum-level resolution is reached )
	JO> The power-draw characteristics certainly does have a set of
underlying combination of frequencies.  Doing any signal analysis on a
typical power trace will show it.  The power trace of a laptop, for
example, is quite different from the power trace for a lamp.
	
	I don't think we made a statement that an ICT device has a flat
energy footprint profile.
	However, the details of that complex aperiodic process are less
interesting to us relative to consumption at intervals meaningful to
billing.

	I see.  That's a fair point.  My main concern was that we don't
miss too many peaks so that it impacts our assessment of the total
energy consumed over extended periods.

		Therefore, we do not have to solve the Nyquist-Shannon
problem here and try to collect samples with frequency above the certain
system-specific limit.
		In fact, whatever we do is already reduced to resolution
of several seconds per sample at the best.
		
		What is likely *more* interesting to us is the behavior
of useful payload in the same period.
		This is related to fact that we can only change power
states if we are sure the certain minimal QoS agreements are reached.

	 

		

		> the sampling frequency
		
		This is a function of integrated PSU sensors. Typically
ranges in Khz.
		However, the operating system itself does not poll the
registers that often; it is more common to have a counter that is
updated every 1-10 seconds or so.
		
		Seems reasonable.

		> and the report frequency.  Without this distinction,
		
		I would agree with Bruce that time aggregates are mostly
a convenience feature.
		
		Sure.  Where the aggregate is computed is not as
important if timestamped power readings are recorded, since the
aggregate can be computed from the traces.

		While every device will have it's own minimal update
resolution, those figures are quite low and not interesting for energy
savings estimates.
		Average 1 min / 5 min/30 min/1hr/24 hr intervals can be
more useful for billing and management purposes.
		
		Another concern is that energy consumed in a
monotonically increasing, so we will run into wrap-out issues.  That
said, Bruce mentioned an averaging window size should be included in the
report.  This would be useful for minimizing value wrap-around.
		
		> If the thing being measured changes slowly, then
reasonable time window.
		
		Alternatively, with reasonable convenience intervals it
may not matter at all.
		
		For the energy management NMS the consumption peaks due
to fan on/off or similar events are not very interesting. It is more
interesting to learn a broader energy use over 1hr-24hr interval with
certain power states activated.
		
		However, please bear in mind that when designing an
energy NMS it is very important to know traffic parameters with
resolution and error counters good enough to approximate usage pattern
with power states.

---

From: "John Parello (jparello)" <[email-masked]>
Date: Fri, 10 Feb 2012 09:36:10 -0800

OK some more thoughts.

Just say a device can report instantaneous power and can't do energy
(I've got tons of those). If the NMS wants to get an idea of the power
over time it would have to poll. Well we know SNMP polls get bogged down
and people don't poll more than say 5-10 minutes.  (netflow may be
different)

IF the devices could collect a series of power reading at faster
intervals it would make sense to have the NMS poll less frequently and
get the series of power readings. That alleviates the need for rapid
polling over the network.

Scale that up to even hundreds of devices with thousands of interfaces
and you're talking a lot of communication saved.

So is it still not useful?

Jp

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jorge
Ortiz
Sent: Thursday, February 09, 2012 9:15 PM
To: John Parello (jparello)
Cc: Bruce Nordman; Daniel Kharitonov; [email-masked]
Subject: Re: [eman] Time series of power measurements

Hi John,

On Fri, Feb 10, 2012 at 9:54 AM, John Parello (jparello)
<[email-masked]> wrote:

Not expressing an opinion either way but I just want to make it clear
for the discussion.

So here's two series of power and energy readings (BTW Both series of
readings misses spikes in the intervals.) 

	Interval    Power   Energy

	0                0W         0kwh

	1            100W    500kwh

	2            120W    600kwh

	3            200W   1000kwh

	4            150W   1350kwh

	5            100W   1500kwh

	 

Jorge

	Jp

	 

	Bruce

	(as contributor)

	Hi Jorge,

	

	

	

	

	

	 

	Hi Jorge,

		

	 

		

		
		Seems reasonable.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Feb 2012 19:31:04 +0100

> So is it still not useful?

Some of the transmission MIBs use PerfHist-TC-MIB definitions to
provide usually 15 minute history counters. And then there is the
DISMAN-EXPRESSION-MIB which might be able to do what you want (and
the next things people will discuss is thresholding - I will then
point to the DISMAN-EVENT-MIB).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Daniel Kharitonov <[email-masked]>
Date: Fri, 10 Feb 2012 11:36:16 -0800

I would be inclined to support Jorge and make a statement that power readings are not as useful in the runtime as energy readings.

If a system only supports power sensors, a local periodic mechanism should be used to integrate power over time and report cumulative energy consumption.

This automatically solves the "frequency of polling" problem.

PS. Acute power readings are indeed useful in assessing peak requirements for a given platform.
This is not runtime activity and is typically done by vendors in the labs as part of qualification process.

From: John Parello (jparello) [mailto:[email-masked]]
Sent: Friday, February 10, 2012 09:36 AM
To: Jorge Ortiz <[email-masked]>
Cc: Bruce Nordman <[email-masked]>; Daniel Kharitonov; [email-masked] <[email-masked]>
Subject: RE: [eman] Time series of power measurements

OK some more thoughts.

Just say a device can report instantaneous power and can’t do energy (I’ve got tons of those). If the NMS wants to get an idea of the power over time it would have to poll. Well we know SNMP polls get bogged down and people don’t poll more than say 5-10 minutes.  (netflow may be different)

IF the devices could collect a series of power reading at faster intervals it would make sense to have the NMS poll less frequently and get the series of power readings. That alleviates the need for rapid polling over the network.

Scale that up to even hundreds of devices with thousands of interfaces and you’re talking a lot of communication saved.

Jp

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jorge Ortiz

Hi John,
On Fri, Feb 10, 2012 at 9:54 AM, John Parello (jparello) <[email-masked]<mailto:[email-masked]>> wrote:
Not expressing an opinion either way but I just want to make it clear for the discussion.

Interval    Power   Energy
0                0W         0kwh
1            100W    500kwh
2            120W    600kwh
3            200W   1000kwh
4            150W   1350kwh
5            100W   1500kwh

That's the claim, yes.  Instantaneous power readings may miss peaks/valleys unless the sampling rate is high enough.

That's a good point.  However, I still think local energy calculations should be made at the meter if possible.  If it's already collecting power data, it might as well integrate over time.

That's actually why I think there should be an instantaneous power reporting service; to handle such cases.

Jorge

Jp

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bruce Nordman
Sent: Thursday, February 09, 2012 3:39 PM
To: Daniel Kharitonov
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Bruce
(as contributor)

On Thu, Feb 9, 2012 at 3:09 PM, Daniel Kharitonov <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jorge,

From: Jorge Ortiz [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, February 09, 2012 02:38 PM
To: Daniel Kharitonov
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [eman] Time series of power measurements

Seems reasonable.

_______________________________________________
eman mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eman

--
Bruce Nordman
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman<http://eetd.lbl.gov/ea/nordman>
[email-masked]<mailto:[email-masked]>
510-486-7089<tel:510-486-7089>
m: 510-501-7943<tel:510-501-7943>