Forums

Instrumenting for power managment

Started by D Yuniskis October 5, 2010
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 :-).