1. 1 Tracking Energy in Networked Embedded System Prabal Dutta Computer Science Division University of California, Berkeley prabal@cs.berkeley.edu http://www.cs.berkeley.edu/~prabal University of Washington – Systems and Networking Seminar – Nov 19, 2008

2. 2 Collaborators on Energy Metering and Profiling SPOT Meter –X. Jiang, D. Culler, I. Stoica (UCB) iCount Meter: –M. Feldmeier, J. Paradiso (MIT) –D. Culler (UCB) Quanto System –R. Fonseca, I. Stoica (UCB) –P. Levis (Stanford) ACme –X. Jiang, S. Dawson-Haggerty, D. Culler (UCB)

3. 3 Motivation: in sensor networks, energy is the defining constraint Battery-operated2 “AA” batteries –10 mA active current –10 uA sleep current –1% duty cycle CPU10 MIPS RAM4 KB to 10 KB ROM32 KB to 128 KB Flash512 KB to 1 MB Radio40 kbps to 250 kbps 2000 mA-Hr

4. 4 Energy-efficient design pervades the research agenda… So, why don’t more publications provide empirical evidence of a change in energy usage? Three challenges make energy profiling hard

5. 5 Three challenges Energy metering –“Measure” energy usage –i(t)  p(t)  ∫p(t)dt Energy tracking –“Slice” usage horizontally Activity tracking –“Dice” usage vertically –Connecting causal dots

6. 6 Outline Introduction Why is it hard and how do you solve it? –Energy Metering (“measuring”) –Energy Tracking (“slicing”) –Activity Tracking (“dicing”) How well does it work? How much does it cost? What are its limitations? How could it be used?

7. 7 Measuring: wide horizontal/vertical dynamic range Transmit packet at 1% duty cycle (20 ms / 2 s)

8. 8 Current energy metering techniques are inadequate cumbersome, expensive, not distributed, not scalable, not embedded, low resolution cumbersome, expensive, not distributed, not scalable, not embedded, low resolution, low responsiveness, high quiescent power low responsiveness, high cost, high quiescent power DS2438 ADM1191 BQ2019 BQ27500 [Jiang07]

9. 9 How simply can energy metering be performed? If your platform has a PFM switching regulator… (increasingly, many do) very simply: iCount energy meter design Prabal Dutta, Mark Feldmeier, Joseph Paradiso, and David Culler, “Energy Metering for Free: Augmenting Switching Regulators for Real-Time Monitoring”, IPSN’08, St. Louis, MO, 2008. Best Paper Award and ISLPED’08 Design Contest Winner.

10. 10 How does it work? Source: Maxim Semiconductor C in LxLx V in C out V out R load i LX Energize Transfer Monitor S1S1 S2S2 V LX E=½Li 2 PFM Regulator

11. 11 Key insight: each regulator cycle transfers a fixed energy quanta to the load ΔE=½Li 2 P=ΔE/ΔtP=ΔE/Δt Counting cycles translates to measuring energy

12. 12 This simple design works surprisingly well MAX1724 Prototype implementation

13. 13 Outline Introduction Why is it hard and how do you solve it? –Energy Metering (“measuring”) –Energy Tracking (“slicing”) –Activity Tracking (“dicing”) How well does it work? How much does it cost? What are its limitations? How can it be used?

14. 14 Slicing: breaking down the envelope into its parts Marc A. Viredaz and Deborah A. Wallach, “Power Evaluation of a Handheld Computer”, IEEE Micro, Jan-Feb, 2003

15. 15 Too many hidden energy sinks! MCU Radio Power FlashSensorsLEDs PowerData Control USART DMA ALU OSC Timer ADC RXTX LNAPA RDWR Erase

16. 16 A different approach: track power states of energy sinks Instrument device drivers –Track device power states –Expose state transitions to OS/App For every state transition –Snapshot system-wide power states (α 1,…, α n ) –Snapshot global energy usage (ΔE) –Snapshot system clock (Δt) Generate an equation of the form ΔE/Δt = α 1 p 1 +… +, α n p n (p’s are the unknown power draws) Solve for p’s using weighted multivariate least squares High-resolution, high-speed energy meter key for good results ΔtΔt ΔEΔE α’s pipi On Off

17. 17 Estimating breakdowns from the aggregate RGBΔEΔEΔtΔt 0008241024 100123361024 010188061024 110304341024 001149401024 101264321024 011328041024 111442471024 Regression Log X = [ones(size(R)) R G B]; p = dE./ dt; i = p / 3; a = X\i; ir=a(2); ig=a(3); ib=a(4);

18. 18 Outline Introduction Why is it hard and how do you solve it? –Energy Metering (“measuring”) –Energy Tracking (“slicing”) –Activity Tracking (“dicing”) How well does it work? How much does it cost? What are its limitations? How can it be used?

19. 19 Dicing: big gap between what is measured and what matters Itsy Measured: –Breakdown by subsystem –Breakdown by application PowerScope Measured: –Breakdown by PC –Breakdown by PID Marc A. Viredaz and Deborah A. Wallach, “Power Evaluation of a Handheld Computer”, IEEE Micro, Jan-Feb, 2003 Jason Flinn and M. Satyanarayanan, “Energy-Aware Adaptation for Mobile Apps.”, SOSP’99, Kiawah Island, SC, 1999

20. 20 What actually matters? Energy metering and tracking show –How much energy is used –When energy is used –Where energy is used But why is the energy being spent? Activity tracking answers the why question –Attributes usage to meaningful resource principals –Not to: threads, processes, tasks, functions, or PC

21. 21 What’s an activity? Connecting the causal dots… A causally-connected set of operations… whose distinct resource consumptions… should be grouped together for accounting* * M.B. Jones et al., “Modular Real-Time Resource Management in the Rialto Operating System”, HotOS’95, 1995. G. Banga et al. “Resource Containers: A New Facility for Resource Management in Server Systems”, OSDI’99,.

22. 22 Three steps to activity tracking Annotating –Application programmers annotate their software –Associates an activity “label” with an execution –Labels are pairs Propagating –System software transfers activity labels –Across subsystems, nodes, and deferred computations Recording –Track, log, and post-process resource usage Rodrigo Fonseca, Prabal Dutta, Philip Levis, and Ion Stoica, Quanto: Tracking Energy in Networked Embedded Systems, OSDI ’08, San Diego, CA, 2008. To appear.

23. 23 Annotating an activity “paints” causally-connected actions “Sensing” involves –Sensor... –CPU, ADC, I2C bus, … “Sending” involves –Radio… –CPU, SPI bus, timers, …... call CPUActivity.set(ACT_SENSING); call Sensor.read(); call CPUActivity.set(ACT_SENDING); call Radio.send(msg);...

24. 24 Propagating activity labels CPU to device –CPU  ADC –CPU  Sensor Node to node –CPU  Radio  Radio  CPU Proxy activity to real activity –Interrupt  CPU –Timer  CPU –Radio  CPU Following logical threads over deferred computation –CPU  Timer  CPU –CPU  Queue  CPU

25. 25 Propagating activity labels from CPU to device (1) Single Activity Device “Paints” device one color Example –CPU  Sensor –CPU  Radio Requires device driver change async command void Sensor.start() { call SensorActivity.set(call CPUActivity.get()); call SensorPowerState.set(1); call SensorImplP.start(); } async command void Sensor.stop() { call SensorActivity.setIdle(); call SensorPowerState.set(0); call SensorImplP.stop(); }

26. 26 Propagating activity labels from CPU to device (2) Multi Activity Device “Paints” device multi color Example –Activity A turns on LED –Activity B turns on LED async command void Leds.led0On() { call Led0Activity.add(call CPUActivity.get()); call Led0PowerState.set(1); call Led0.clr(); } async command void Leds.led0Off() { call Led0Activity.setIdle(); call Led0PowerState.set(0); call Led0.set(); }

27. 27 Propagating activity labels from node to node Add hidden field to packet Sender’s OS sets activity field command void Radio.send(message_t* msg) {... msg->header->activity = call CPUContext.get();... }

28. 28 Propagating and binding activity labels to proxy activities Interrupts cause energy consumption before activity label is identified –Interrupt  CPU –Timer  CPU –Radio  CPU event message_t* Radio.recv(message_t* msg, void* payload, uint8_t len) {... call CPUContext.bind(msg->hdr->activity);... } Proxy activity provides ephemeral label Binding with real activity occurs when label is clear

29. 29 Propagating activity labels through deferred computations Examples –CPU  Task  CPU –CPU  Timer  CPU –CPU  Queue  CPU Scheduler/Timer entry extended –Add activity field –Set activity field on task posting / Timer.start –Restore activity on task invocation /Timer.fired Queue –Add array (linked list) of activities to Queue –Write (enqueue) activity label on Queue.enqueue –Restore (dequeue) activity label on Queue.dequeue

30. 30 Summary: Quanto energy profiling architecture Device Drivers Hardware Application Operating System,,,,, scheduler propagate labels over deferred computations interrupts monitor/expose power statessave/restore/expose activity Energy Meter Perform regressions, compute energy breakdowns annotate code with activity labels log power states, and time and energy usage arbiters timersqueues propagate labels to/from devices call CPUActivity.set(ACT_SENSING); log activity labels Allocate usage to activities

31. 31 Outline Introduction Why is it hard and how do you solve it? How well does it work? –Energy Meter –Energy Tracking How much does it cost? What are its limitations? How can it be used?

32. 32 Energy metering: performance summary Performance MetriciCount Range1 µA – 100 mA Accuracy±20% over 5 decades Resolution0.1 µJ – 0.5 µJ Read latency24 CPU cycles (24 µs) Power overhead1% - 0.01% Responsiveness< 125 µs Precision±1.5% (over 2 secs) Stability±1% (over 1 week)* * Frequency averaged over 1 second

33. 33 Energy tracking: ground truth and regression results agree Oscilloscope Ground Truth Quanto Regression 48 seconds of Blink

34. 34 Outline Introduction Why is it hard and how do you solve it? How well does it work? How much does it cost? –Micro Benchmarks –Macro Benchmarks What are its limitations? How can it be used?

35. 35 How much does it cost? Hardware –PFM regulator + wire –Microcontroller counter Software –iCount –Quanto Modified < 350 LOC Added 1275 new LOC

36. 36 Software modifications (Quanto)

37. 37 How much does it cost? Space –12 bytes per energy or activity sample –Logging: RAM buffer 800 samples @ 12 bytes each Time –Reading timer: 19 CPU cycles –Reading iCount: 24 CPU cycles –Logging a sample: 102 CPU cycles (total) –Logging Blink App 597 samples / 48 seconds 0.12% of CPU time (60.71 ms / 48 s) 71% of CPU active time –Reporting Blink App: between 4% and 15% of CPU time Energy –1% of sleep current (90 nA / 9 µA) –0.01% of active current (90 nA / 9 µA) –Logging Blink App: 0.08% energy (0.41 mJ)

38. 38 Outline Introduction Why is it hard and how do you solve it? How well does it work? How much does it cost? What are its limitations? How can it be used?

39. 39 Limitations Energy Metering –Requires hardware support –Input voltage dependence  Requires calibration –Hardware tolerances  Requires calibrations Energy Tracking –Assumes visibility into device power states –Assume constant per-state power draws –Assumes linearly independent equations –Requires device driver modifications Activity Tracking –Reentrancy not supported –Requires OS modifications

40. 40 Outline Introduction Why is it hard and how do you solve it? How well does it work? How much does it cost? What are its limitations? How can it be used?

41. 41 Where have all the Joules gone? 48 seconds of Blink “Slice” by device “Dice” by activity

42. 42 Where have all the (milli)seconds gone? 48 seconds of BlinkActivity tracking

43. 43 What’s the cost of overhearing in Low-Power Listening?

44. 44 What’s going on? Why is TIMERA firing at 16Hz?

45. 45 What’s the network-wide cost of a routing update? …we’re still working on that one Toy example of node to node transfer in paper Challenge: getting data off the node

46. 46 Outline Introduction Why is it hard and how do you solve it? How well does it work? How much does it cost? What are its limitations? How can it be used?

47. 47 Summary += call CPUActivity.set(ACT_LED0);... call CPUActivity.set(ACT_LED1);... call CPUActivity.set(ACT_LED2); Measure Slice Dice

48. 48 Discussion

49. 49 Backup Slides

50. 50 Random

51. 51 Power draw characteristics

52. 52 Energy profiling architecture and implementation Device Drivers Hardware Application Operating System,,,,, scheduler propagate labels over deferred computations interrupts monitor/expose power statessave/restore/expose activity Energy Meter Offline: perform regressions, compute energy breakdowns, allocate usage to activities annotate code with activity labels log power states, activity labels, and time and energy usage, arbiters timersqueues propagate labels to/from devices call CPUActivity.set(ACT_SENSING);

53. 53 Annotating an activity “paints” causally-connected actions task void sensorTask() { call CPUActivity.set(ACT_HUM); call Humidity.read(); call CPUActivity.set(ACT_TEMP); call Temperature.read(); } void sendIfDone() { if (sensingDone) { call CPUActivity.set(ACT_PKT); post sendTask(); sensingDone = 0; }

54. 54 Many scientific data collection applications stream sensor data from sensor nodes to sinks SELECT* FROMsensors SAMPLE PERIOD5 min SELECTtime, epoch, id, parent, voltage, depth, hum, temp, toplight, botlight FROMsensors SAMPLE PERIOD5 min “Redwoods” [Tolle05] “Great Duck Island” [Szewczyk04]

55. 55 Motivation for tracking activities TIMERB fires VTimer callback Timer.fired() callback –Sensor.start() invoked ADC.start() invoked … ADC.startDone() callback –Sensor.startDone() callback Sensor.read() invoked –ADC.read() … ADC.readDone() callback –Sensor.readDone(x) callback Sensor.stop() invoked –ADC.stop() invoked … ADC.stopDone() callback –Sensor.stopDone() callback Radio.start() invoked … Radio.startDone() callback –Radio.send(x) … Sense Send

56. 56 Outline Introduction How does it work? How well does it work? –Range –Accuracy –Resolution –Responsiveness –Precision –Stability How much does it cost? What are its limitations? How could it be used?

57. 57 Performance summary Performance MetriciCount Range1 µA – 100 mA Accuracy±20% Resolution0.1 µJ – 0.5 µJ Read latency24 µs Power overhead1% - 0.01% Responsiveness< 125 µs Precision±1.5% (over 2 secs) Stability±1% (over 1 week)* * Frequency averaged over 1 second

58. 58 Range: motes exhibit 10000:1 dynamic range (5 µA - 50 mA) iCount offers a dynamic range exceeding 100000:1

59. 59 Accuracy: iCount exhibits less than ±20% error over five decades of current draw Common Operating Points iCount exhibits lower error over mote operating range

60. 60 Resolution: A Telos mote uses about 20 µJ per second when sleeping iCount resolves less than 1 µJ

61. 61 Responsiveness: A mote’s energy-consuming events can occur in as little as 100 µs [Jiang07] iCount responds in less than 125 µs to sudden changes in current draw

62. 62 Precision: precise over short periods (2 sec) so one or two samples is enough to estimate the instantaneous current All samples fall within ±2% of the median

63. 63 Stability: iCount is stable over long periods (1 week) All samples fall within ±1% of the median

64. 64 Outline Introduction Why is it hard and how do you solve it? How well does it work? How much does it cost? –Micro Benchmarks –Macro Benchmarks What are its limitations? How can it be used?

65. 65 Hardware costs: wire and counter “wire” Counter HydroSolar Node (v2)

66. 66 Energy costs: gate switching, counter overflows 1% 0.01%

67. 67 Software costs (iCount) Control Access (24 CPU cycles / 24 µs) Overflow Initialization

68. 68 Software costs (Quanto)

69. 69 Space and Time costs

70. 70 Outline Introduction Why is it hard and how do you solve it? How well does it work? How much does it cost? What are its limitations? How can it be used?

71. 71 Input voltage dependence requires calibration (not fundamental, but an artifact of the MAX1724)

72. 72 Calibration is required either at manufacturing or at run-time Calibration Reg

73. 73 Regulator inefficiency makes battery gas gauging challenging

74. 74 Is hardware energy metering really needed?