Instrumenting for power managment

Hi,

I have an application that is extremely power conscious
(VERY long uptimes on battery, etc.).  It sees lots of extended
usage -- i.e., can benefit from "watching itself".  The RTOS
and API have special hooks to support power management very
elegantly in a fine-grained manner.  I.e., the application
has the tools it needs to optimize its power consumption
*if* it knows what that is!

I'm looking for suggestions as to the least invasive means of
monitoring actual power consumption in an equally fine-grained
manner.

Note that I am *not* interested in monitoring battery state
(that's a separate problem) but, rather, characterizing the
load, instead.   And, *dynamically*!  E.g., conceptually, I
should be able to assign a numeric "power burden" to each
activity performed by the device.  I and/or the device could
then decide how best to spend the *current* "available power".

[perhaps this is best posted to s.e.d?]

--don

On Tue, 05 Oct 2010 07:51:04 -0700, D Yuniskis
<not.going.to.be@seen.com> wrote:

>Hi,
>
>I have an application that is extremely power conscious
>(VERY long uptimes on battery, etc.).  It sees lots of extended
>usage -- i.e., can benefit from "watching itself".  The RTOS
>and API have special hooks to support power management very
>elegantly in a fine-grained manner.  I.e., the application
>has the tools it needs to optimize its power consumption
>*if* it knows what that is!
>
>I'm looking for suggestions as to the least invasive means of
>monitoring actual power consumption in an equally fine-grained
>manner.

Assuming the processor has a nearly zero power wait_for_interrupt
instruction or state, just monitor, how long each routine is
executing.

A typical small RTOS will just scan the task list after a significant
event (interrupt completed or task state change) to find the highest
priority runnable task and execute it. If no runnable tasks have been
detected, go to sleep to wait for the next interrupt.
 
Time stamping at the scheduler should give an estimate, how long a
task is executing and how much power it is consumed.

In article <ivima6hisvh1i406uabuorc3625lkjg86c@4ax.com>, keinanen@sci.fi 
says...
> On Tue, 05 Oct 2010 07:51:04 -0700, D Yuniskis
> <not.going.to.be@seen.com> wrote:
> 
> >Hi,
> >
> >I have an application that is extremely power conscious
> >(VERY long uptimes on battery, etc.).  It sees lots of extended
> >usage -- i.e., can benefit from "watching itself".  The RTOS
> >and API have special hooks to support power management very
> >elegantly in a fine-grained manner.  I.e., the application
> >has the tools it needs to optimize its power consumption
> >*if* it knows what that is!
> >
> >I'm looking for suggestions as to the least invasive means of
> >monitoring actual power consumption in an equally fine-grained
> >manner.
> 
> Assuming the processor has a nearly zero power wait_for_interrupt
> instruction or state, just monitor, how long each routine is
> executing.
> 
> A typical small RTOS will just scan the task list after a significant
> event (interrupt completed or task state change) to find the highest
> priority runnable task and execute it. If no runnable tasks have been
> detected, go to sleep to wait for the next interrupt.
>  
> Time stamping at the scheduler should give an estimate, how long a
> task is executing and how much power it is consumed.
> 
> 
A very low-power processor may expend a significant part of
its power in peripheral operations.  That can be particularly
true with high speed clocks to things like SPI-connected
peripherals.   Different tasks may have different power drain
in the same time interval.


In some applications, I've found it useful to use a high-side
current monitoring chip (MAX471 or equivalent).   I generally
filter the output with an RC filter and sample the current
as part of the internal timer tick chore.   The trick is to
balance the power drain from the monitoring and record-keeping
against the need for the data.

Mark Borgerson

Hi Paul,

Paul Keinanen wrote:
> On Tue, 05 Oct 2010 07:51:04 -0700, D Yuniskis
> 
>> I have an application that is extremely power conscious
>> (VERY long uptimes on battery, etc.).  It sees lots of extended
>> usage -- i.e., can benefit from "watching itself".  The RTOS
>> and API have special hooks to support power management very
>> elegantly in a fine-grained manner.  I.e., the application
>> has the tools it needs to optimize its power consumption
>> *if* it knows what that is!
>>
>> I'm looking for suggestions as to the least invasive means of
>> monitoring actual power consumption in an equally fine-grained
>> manner.
> 
> Assuming the processor has a nearly zero power wait_for_interrupt
> instruction or state, just monitor, how long each routine is
> executing.

That doesn't address the power used in I/O devices, etc.
It also doesn't work well in an environment where every/most
task is using it's entire timeslot (i.e., this *looks* like
each task is using an "equal amount" of time/"power").
Finally, it doesn't address the "work" done by each task
and the "cost" of that "work" (e.g., a task that is running
lots of back-to-back multiply-and-accumulates is undoubtedly
putting a bigger strain on resources than one that is twiddling
bits in a register).

> A typical small RTOS will just scan the task list after a significant
> event (interrupt completed or task state change) to find the highest
> priority runnable task and execute it. If no runnable tasks have been
> detected, go to sleep to wait for the next interrupt.

That's not a problem -- assuming you ignore the cost of I/O's
that happen to be running "in the absence" of executing code
(and the cost of their IRQs).

> Time stamping at the scheduler should give an estimate, how long a
> task is executing and how much power it is consumed.

I think that would only work for trivial tasks that use "comparable"
resources.  E.g., a task/process that has wired down 100M of
address space is probably costing you more than one that executes
in 3KB  :-/

Part of the effort is to determine when it makes sense to scale
back algorithms that burn power to gain speed in favor of other
approaches that sacrifice speed to conserve power.  Without those
metrics, you can't even tell the *user* what his choices *might* be!

Hi Mark,

Mark Borgerson wrote:
> In article <ivima6hisvh1i406uabuorc3625lkjg86c@4ax.com>, keinanen@sci.fi 
> says...
>> On Tue, 05 Oct 2010 07:51:04 -0700, D Yuniskis
>> <not.going.to.be@seen.com> wrote:
>>
>>> I have an application that is extremely power conscious
>>> (VERY long uptimes on battery, etc.).  It sees lots of extended
>>> usage -- i.e., can benefit from "watching itself".  The RTOS
>>> and API have special hooks to support power management very
>>> elegantly in a fine-grained manner.  I.e., the application
>>> has the tools it needs to optimize its power consumption
>>> *if* it knows what that is!
>>>
>>> I'm looking for suggestions as to the least invasive means of
>>> monitoring actual power consumption in an equally fine-grained
>>> manner.
>> Assuming the processor has a nearly zero power wait_for_interrupt
>> instruction or state, just monitor, how long each routine is
>> executing.
>>
>> A typical small RTOS will just scan the task list after a significant
>> event (interrupt completed or task state change) to find the highest
>> priority runnable task and execute it. If no runnable tasks have been
>> detected, go to sleep to wait for the next interrupt.
>>  
>> Time stamping at the scheduler should give an estimate, how long a
>> task is executing and how much power it is consumed.
>
> A very low-power processor may expend a significant part of
> its power in peripheral operations.  That can be particularly
> true with high speed clocks to things like SPI-connected

Exactly.  Or, what's the cost of "displaying" information
(vs. the cost of *preserving* it?!)

You also have tasks that can quickly (in terms of CPU cycles)
do things that result (eventually) in big power consumption.
For example, turning on the "vibrator" (e.g., in a phone).
This can probably be done in 10 CPU clock cycles -- yet burn
enough power to run the entire processor for more time than the
annunciator is active!

> peripherals.   Different tasks may have different power drain
> in the same time interval.
> 
> In some applications, I've found it useful to use a high-side
> current monitoring chip (MAX471 or equivalent).   I generally
> filter the output with an RC filter and sample the current
> as part of the internal timer tick chore.   The trick is to
> balance the power drain from the monitoring and record-keeping
> against the need for the data.

But I suspect you are just trying to track your *total* power
consumption -- not "charge" that to a particular "task"?
I.e., you just want to know when you are headed for disaster
and then, perhaps, implement some a priori scheme for conserving
power (?).

I'm wanting to look at the costs of particular activities and
adjust them dynamically to *manage* power in just the same
way you would manage "execution time", "memory", "temperature",
etc. in a device.

In article <i8fti3$n2c$1@speranza.aioe.org>, not.going.to.be@seen.com 
says...
> Hi Mark,
> 
> Mark Borgerson wrote:
> > In article <ivima6hisvh1i406uabuorc3625lkjg86c@4ax.com>, keinanen@sci.fi 
> > says...
> >> On Tue, 05 Oct 2010 07:51:04 -0700, D Yuniskis
> >> <not.going.to.be@seen.com> wrote:
> >>
> >>> I have an application that is extremely power conscious
> >>> (VERY long uptimes on battery, etc.).  It sees lots of extended
> >>> usage -- i.e., can benefit from "watching itself".  The RTOS
> >>> and API have special hooks to support power management very
> >>> elegantly in a fine-grained manner.  I.e., the application
> >>> has the tools it needs to optimize its power consumption
> >>> *if* it knows what that is!
> >>>
> >>> I'm looking for suggestions as to the least invasive means of
> >>> monitoring actual power consumption in an equally fine-grained
> >>> manner.
> >> Assuming the processor has a nearly zero power wait_for_interrupt
> >> instruction or state, just monitor, how long each routine is
> >> executing.
> >>
> >> A typical small RTOS will just scan the task list after a significant
> >> event (interrupt completed or task state change) to find the highest
> >> priority runnable task and execute it. If no runnable tasks have been
> >> detected, go to sleep to wait for the next interrupt.
> >>  
> >> Time stamping at the scheduler should give an estimate, how long a
> >> task is executing and how much power it is consumed.
> >
> > A very low-power processor may expend a significant part of
> > its power in peripheral operations.  That can be particularly
> > true with high speed clocks to things like SPI-connected
> 
> Exactly.  Or, what's the cost of "displaying" information
> (vs. the cost of *preserving* it?!)
> 
> You also have tasks that can quickly (in terms of CPU cycles)
> do things that result (eventually) in big power consumption.
> For example, turning on the "vibrator" (e.g., in a phone).
> This can probably be done in 10 CPU clock cycles -- yet burn
> enough power to run the entire processor for more time than the
> annunciator is active!
> 
> > peripherals.   Different tasks may have different power drain
> > in the same time interval.
> > 
> > In some applications, I've found it useful to use a high-side
> > current monitoring chip (MAX471 or equivalent).   I generally
> > filter the output with an RC filter and sample the current
> > as part of the internal timer tick chore.   The trick is to
> > balance the power drain from the monitoring and record-keeping
> > against the need for the data.
> 
> But I suspect you are just trying to track your *total* power
> consumption -- not "charge" that to a particular "task"?
> I.e., you just want to know when you are headed for disaster
> and then, perhaps, implement some a priori scheme for conserving
> power (?).

That's true.  I generally look at overall power consumption
for a fairly fixed set of data logging tasks.  I go a bit
finer grain when looking at the cost of individual tasks,
such a writing a block to SD, but I'm mostly concerned about
how many months an instrument will be able to log data with
a particular set of lithium primary cells.

However, I suppose that a high-priority interrupt could
measure power and assign the measured current to the
task which it had preempted.
> 
> I'm wanting to look at the costs of particular activities and
> adjust them dynamically to *manage* power in just the same
> way you would manage "execution time", "memory", "temperature",
> etc. in a device.
> 

OK.  That is a bit different.  I generally work with a fixed
set of tasks that allows little flexibility.  About all I can
decide is whether to use 1, 2 or 4KB of buffer before I write
to SD.

Mark

Hi Mark,

[much elided]

Mark Borgerson wrote:
>>> In some applications, I've found it useful to use a high-side
>>> current monitoring chip (MAX471 or equivalent).   I generally
>>> filter the output with an RC filter and sample the current
>>> as part of the internal timer tick chore.   The trick is to
>>> balance the power drain from the monitoring and record-keeping
>>> against the need for the data.
>> But I suspect you are just trying to track your *total* power
>> consumption -- not "charge" that to a particular "task"?
>> I.e., you just want to know when you are headed for disaster
>> and then, perhaps, implement some a priori scheme for conserving
>> power (?).
> 
> That's true.  I generally look at overall power consumption
> for a fairly fixed set of data logging tasks.  I go a bit
> finer grain when looking at the cost of individual tasks,
> such a writing a block to SD, but I'm mostly concerned about
> how many months an instrument will be able to log data with
> a particular set of lithium primary cells.

Yes.  Sorry, I should have elaborated on the different
nature of the application  :-/

E.g., in your case, you're pretty much pared down to doing
the *least* that you can -- while still satisfying your
overall design goals.  So, there's nothing to "throw away"
when power gets in short supply.

And, power reserves are a monotonically decreasing function;
you *know* you'll have less power available at EVERY time
in the future than you have now.

> However, I suppose that a high-priority interrupt could
> measure power and assign the measured current to the
> task which it had preempted.

I'm not sure whether just taking a snapshot of the *current*
(taking your comment literally) would work.  I.e., that assumes
it has been constant over the past quantum.  I think you
have to integrate *power* consumed instead of just looking
at instantaneous current.

Also, assuming that the power consumed "now" is chargeable
to the "recent task" can be misleading.  Especially in synchronous
environments.  E.g., task A starts some (hardware) process/device,
then blocks.  Power consumption changes *while* task B (which follows
task A) executes and B is charged with that -- even though the
power consumed was a result of A's actions!  I.e., if B is unlucky
enough to get stuck following A all/most of the time, then B is
wrongly accused of using more power than it actually *did*.

(the same problem happens in *time* when A sets up an ISR that
occurs *during* B's time slot -- B pays the price for A's actions
by losing the CPU cycles that A's ISR consumed)

>> I'm wanting to look at the costs of particular activities and
>> adjust them dynamically to *manage* power in just the same
>> way you would manage "execution time", "memory", "temperature",
>> etc. in a device.
> 
> OK.  That is a bit different.  I generally work with a fixed
> set of tasks that allows little flexibility.  About all I can
> decide is whether to use 1, 2 or 4KB of buffer before I write
> to SD.

Understood.  I'm trying to come up with metrics that can let
the "application set" tune itself to better use available power;
*and*, so that "it" can better inform the user of the costs of
particular user actions.

E.g., if your cell phone told you that "listening to music (MP3's)"
is costing you W minutes of talk time per minute of music "consumed"
or X minutes of standby time *and* you currently only have Y/Z minutes
of talk/standby time ON RESERVE, then you could better manage your
phone usage -- ESPECIALLY IF RECHARGING IS NOT PRESENTLY AN OPTION!

I haven't found anything that addresses this sort of issue to date.
Instead, any metrics tend to look at the *overall* power consumption
and, at best, say (in effect) "if you keep using the device in the
same way that you have *been* using the device recently, then the best
estimate is that you have X reserves available".  This is essentially
useless information as it doesn't let the user know how to *change*
his usage pattern to alter those reserves -- nor the *range* of
possible reserves that he might attain best'/worst case *if* he
altered his usage patterns! (e.g., if drastically altering usage
only results in a tiny incremental advance in reserves, then the
user might as well keep doing what he is doing!)

In article <i8g2tb$2or$1@speranza.aioe.org>, not.going.to.be@seen.com 
says...
> Hi Mark,
> 
> [much elided]
> 
> Mark Borgerson wrote:
> >>> In some applications, I've found it useful to use a high-side
> >>> current monitoring chip (MAX471 or equivalent).   I generally
> >>> filter the output with an RC filter and sample the current
> >>> as part of the internal timer tick chore.   The trick is to
> >>> balance the power drain from the monitoring and record-keeping
> >>> against the need for the data.
> >> But I suspect you are just trying to track your *total* power
> >> consumption -- not "charge" that to a particular "task"?
> >> I.e., you just want to know when you are headed for disaster
> >> and then, perhaps, implement some a priori scheme for conserving
> >> power (?).
> > 
> > That's true.  I generally look at overall power consumption
> > for a fairly fixed set of data logging tasks.  I go a bit
> > finer grain when looking at the cost of individual tasks,
> > such a writing a block to SD, but I'm mostly concerned about
> > how many months an instrument will be able to log data with
> > a particular set of lithium primary cells.
> 
> Yes.  Sorry, I should have elaborated on the different
> nature of the application  :-/
> 
> E.g., in your case, you're pretty much pared down to doing
> the *least* that you can -- while still satisfying your
> overall design goals.  So, there's nothing to "throw away"
> when power gets in short supply.
> 
> And, power reserves are a monotonically decreasing function;
> you *know* you'll have less power available at EVERY time
> in the future than you have now.

Well, that's ALMOST true.  However, the polarization effects
on chemical batteries can result in short-term increases
in cell resistance that disappear after a resting period.
I've had that result in systems that reset when writing
to SD, then re-awaken and run OK a while later.  That
requires good brown-out detection and hysteresis in the
reset generator.
> 
> > However, I suppose that a high-priority interrupt could
> > measure power and assign the measured current to the
> > task which it had preempted.
> 
> I'm not sure whether just taking a snapshot of the *current*
> (taking your comment literally) would work.  I.e., that assumes
> it has been constant over the past quantum.  I think you
> have to integrate *power* consumed instead of just looking
> at instantaneous current.

That's the reason that I usually have a pretty long time
constant in the RC filter on the current sensor.
> 
> Also, assuming that the power consumed "now" is chargeable
> to the "recent task" can be misleading.  Especially in synchronous
> environments.  E.g., task A starts some (hardware) process/device,
> then blocks.  Power consumption changes *while* task B (which follows
> task A) executes and B is charged with that -- even though the
> power consumed was a result of A's actions!  I.e., if B is unlucky
> enough to get stuck following A all/most of the time, then B is
> wrongly accused of using more power than it actually *did*.

I guess you would have to not only capture which task is running,
but the state of various peripherals. Then the monitoring task
is starting to consume a significant percentage of the current
in shorter tasks.
> 
> (the same problem happens in *time* when A sets up an ISR that
> occurs *during* B's time slot -- B pays the price for A's actions
> by losing the CPU cycles that A's ISR consumed)
> 
> >> I'm wanting to look at the costs of particular activities and
> >> adjust them dynamically to *manage* power in just the same
> >> way you would manage "execution time", "memory", "temperature",
> >> etc. in a device.
> > 
> > OK.  That is a bit different.  I generally work with a fixed
> > set of tasks that allows little flexibility.  About all I can
> > decide is whether to use 1, 2 or 4KB of buffer before I write
> > to SD.
> 
> Understood.  I'm trying to come up with metrics that can let
> the "application set" tune itself to better use available power;
> *and*, so that "it" can better inform the user of the costs of
> particular user actions.
> 
> E.g., if your cell phone told you that "listening to music (MP3's)"
> is costing you W minutes of talk time per minute of music "consumed"
> or X minutes of standby time *and* you currently only have Y/Z minutes
> of talk/standby time ON RESERVE, then you could better manage your
> phone usage -- ESPECIALLY IF RECHARGING IS NOT PRESENTLY AN OPTION!
> 
> I haven't found anything that addresses this sort of issue to date.
> Instead, any metrics tend to look at the *overall* power consumption
> and, at best, say (in effect) "if you keep using the device in the
> same way that you have *been* using the device recently, then the best
> estimate is that you have X reserves available".  This is essentially
> useless information as it doesn't let the user know how to *change*
> his usage pattern to alter those reserves -- nor the *range* of
> possible reserves that he might attain best'/worst case *if* he
> altered his usage patterns! (e.g., if drastically altering usage
> only results in a tiny incremental advance in reserves, then the
> user might as well keep doing what he is doing!)
> 

This is definitely a more complex problem than those I have
faced.  Good Luck.


Mark Borgerson

Hi Mark,

Mark Borgerson wrote:

[much elided]

>>> That's true.  I generally look at overall power consumption
>>> for a fairly fixed set of data logging tasks.  I go a bit
>>> finer grain when looking at the cost of individual tasks,
>>> such a writing a block to SD, but I'm mostly concerned about
>>> how many months an instrument will be able to log data with
>>> a particular set of lithium primary cells.
>> Yes.  Sorry, I should have elaborated on the different
>> nature of the application  :-/
>>
>> E.g., in your case, you're pretty much pared down to doing
>> the *least* that you can -- while still satisfying your
>> overall design goals.  So, there's nothing to "throw away"
>> when power gets in short supply.
>>
>> And, power reserves are a monotonically decreasing function;
>> you *know* you'll have less power available at EVERY time
>> in the future than you have now.
> 
> Well, that's ALMOST true.  However, the polarization effects
> on chemical batteries can result in short-term increases
> in cell resistance that disappear after a resting period.

Yes.  But that assumes you can "power off" and then power
back on.  I had assumed your devices got turned on, sealed
up, thrown overboard and then fished out sometime later
(possibly *after* the batteries had been exhausted).

In my case, the device can be powered off, recharged, etc.
so making decisions about "The Future" has one extra
unknown (i.e., when/if/how-much power will be reintroduced
to the battery)

> I've had that result in systems that reset when writing
> to SD, then re-awaken and run OK a while later.  That
> requires good brown-out detection and hysteresis in the
> reset generator.
>>> However, I suppose that a high-priority interrupt could
>>> measure power and assign the measured current to the
>>> task which it had preempted.
>> I'm not sure whether just taking a snapshot of the *current*
>> (taking your comment literally) would work.  I.e., that assumes
>> it has been constant over the past quantum.  I think you
>> have to integrate *power* consumed instead of just looking
>> at instantaneous current.
> 
> That's the reason that I usually have a pretty long time
> constant in the RC filter on the current sensor.

But, you don't "reset" that at the start of the next
integration period (?) -- presumably, you could "do the math"
to eliminate the need for this?

I was thinking more along the lines of integrating the
charge pulses coming out of the inverter(s) and using that
to reflect the near-instantaneous demands of the system
(assuming you chop at a frequency >> the jiffy)

>> Also, assuming that the power consumed "now" is chargeable
>> to the "recent task" can be misleading.  Especially in synchronous
>> environments.  E.g., task A starts some (hardware) process/device,
>> then blocks.  Power consumption changes *while* task B (which follows
>> task A) executes and B is charged with that -- even though the
>> power consumed was a result of A's actions!  I.e., if B is unlucky
>> enough to get stuck following A all/most of the time, then B is
>> wrongly accused of using more power than it actually *did*.
> 
> I guess you would have to not only capture which task is running,
> but the state of various peripherals. Then the monitoring task
> is starting to consume a significant percentage of the current
> in shorter tasks.

Yes.  Though you can decide that certain tasks can be efffectively
approximated by "Kt" (you can determine this a priori by looking at how
they behave "on the bench").

The big problem is the power hungry tasks -- those that intentionally
use peripherals that draw lots of power *or* those that, by their
nature, *need* lots of resources to achieve their goals.

E.g., to fall back on the cell phone analogy, I suspect you
could track power in the radio and backlight and get a good
first-order handle on overall consumption.  So, showing the
user the (relative?) costs of "talking" vs. "looking at
the screen" vs. "waiting for a call" shouldn't be difficult.

>> (the same problem happens in *time* when A sets up an ISR that
>> occurs *during* B's time slot -- B pays the price for A's actions
>> by losing the CPU cycles that A's ISR consumed)
>>
>>>> I'm wanting to look at the costs of particular activities and
>>>> adjust them dynamically to *manage* power in just the same
>>>> way you would manage "execution time", "memory", "temperature",
>>>> etc. in a device.
>>> OK.  That is a bit different.  I generally work with a fixed
>>> set of tasks that allows little flexibility.  About all I can
>>> decide is whether to use 1, 2 or 4KB of buffer before I write
>>> to SD.
>> Understood.  I'm trying to come up with metrics that can let
>> the "application set" tune itself to better use available power;
>> *and*, so that "it" can better inform the user of the costs of
>> particular user actions.
>>
>> E.g., if your cell phone told you that "listening to music (MP3's)"
>> is costing you W minutes of talk time per minute of music "consumed"
>> or X minutes of standby time *and* you currently only have Y/Z minutes
>> of talk/standby time ON RESERVE, then you could better manage your
>> phone usage -- ESPECIALLY IF RECHARGING IS NOT PRESENTLY AN OPTION!
>>
>> I haven't found anything that addresses this sort of issue to date.
>> Instead, any metrics tend to look at the *overall* power consumption
>> and, at best, say (in effect) "if you keep using the device in the
>> same way that you have *been* using the device recently, then the best
>> estimate is that you have X reserves available".  This is essentially
>> useless information as it doesn't let the user know how to *change*
>> his usage pattern to alter those reserves -- nor the *range* of
>> possible reserves that he might attain best'/worst case *if* he
>> altered his usage patterns! (e.g., if drastically altering usage
>> only results in a tiny incremental advance in reserves, then the
>> user might as well keep doing what he is doing!)
> 
> This is definitely a more complex problem than those I have
> faced.  Good Luck.

<grin>  I suspect this will become more commonplace as I can't
see battery technology progressing much faster than our demands
for features, etc.  Decades ago, 100% CMOS processors were
few and far between (1802, 8085 and perhaps 6502 variants?).
Then "sleep modes" on processors (often crudely timer driven
instead of any particular heuristics).  Sooner or later,
you will be able to query the core itself for an accounting of
its recent power requirements...

On Tue, 05 Oct 2010 13:53:22 -0700, D Yuniskis
<not.going.to.be@seen.com> wrote:

>
>E.g., if your cell phone told you that "listening to music (MP3's)"
>is costing you W minutes of talk time per minute of music "consumed"
>or X minutes of standby time *and* you currently only have Y/Z minutes
>of talk/standby time ON RESERVE, then you could better manage your
>phone usage -- ESPECIALLY IF RECHARGING IS NOT PRESENTLY AN OPTION!

What figure are you going to report to the user in this example ?

The time remaining at minimum cellular transmitter power ?

The time remaining at maximum cellular transmitter power ?

The time remaining at most recent phone contact transmitter power ?

After all, a user movement of less than one meter would make all
alternatives viable. Of course, telling the worst case time could
require using the full handset transmitter power, while the marketing
department would expect you to tell the time available, when climbing
the cellular tower :-).