1. Power and Control in Networked Sensors E. Jason Riedy and Robert Szewczyk Presenter: Fayun Luo

2. Outline Introduction Real System Experiment One Processor Analysis Multiple Processor Analysis Summary Related Work

3. Introduction Resource Constraints in WSN  CPU speed  Memory  Communication Bandwidth  Power

4. Energy Constraints Not feasible to replenish the energy in deployed sensors Current Battery has very limited capacity Battery technology has been improving at only a modest pace

5. Architecture Design Dilemma A typical PC: many processors Current networked sensor: one single processor Dilemma: one processor or multiple processors?

6. Intuition Multiple processors  lower frequency Lower frequency  lower current and voltage Multiple processors  meet real time constraints better Tradeoffs: Communication between processors is not free Allocating tasks to processors may be really hard

7. Roadmap

8. Recap - Berkeley Motes ProcessorAtmel AVR, 4MHz, 8-bit, 8KB inst mem and 512 bytes data mem RadioFR Monolithics 916.5MHz, Speed up to 19.2 Kbps Temperature Sensor Analog Devices AD7418, I 2 C protocol Light Sensor Photoresistor, 10  ~50 

9. Recap - TinyOS Event-driven architecture Simple FIFO scheduler + graph of components Two level scheduling: events and tasks Events preempt tasks single shared stack

10. Microbenchmarks Turn_off_all_devices Setup While(1) { Flash_Trigger_Pin Body } For I = 0 to N { InstX InstX … InstX } Turn_on_lightSensor()

11. Instructions and Modules Experiment Result

12. Questions about Mote Experiment How about experiment on other Motes? How do we measure the communication cost? Mote TypeProcessor Berkeley MotesOne Atmel AVR chip MIT µAMPSTwo dedicated chips UCLA MedusaTwo chips Rockwell WINS32-bit RISC processor + one dedicated microcontroller The paper claims the communication cost is free. Do you buy it?

13. TinyOS Experiment Result

14. Questions about TinyOS Experiment How about other OS? Different Scheduler? Different event-task model?

15. Roadmap

16. Architecture Model – Hardware Model One central processor controls many ‘dumb’ devices, while each ‘intelligent’ device has a dedicated processor

17. Architecture Model – Task Model Example: T = 1 sec f = 4,000,000 Hz K = 2,000,000 cycles  = 2,000,000 / (1 * 4,000,000) = 0.5 f m = 2,000,000 / 1 = 2,000,000 Hz

18. Questions About the Assumptions of Task Model Is the time span periodic in real world? What might be different between different schedulers?

19. Architecture Model – Energy Model T I(t) I(f) We will focus on I(f)

20. Current Model f I I active I Idle f I IAIA The bottom line is: all our current models are linear. Define

21. One Processor Mathematical Model Question: Does it model power off and power save mode? Note: f,  are dependent,  = f m /f  I active (f ) (1-  )I idle (f)

22. One Processor Analysis In a single processor, frequency is the main parameter we can adjust: Case 1:  opt <= 1Case 2:  opt >= 1 run as low as possible Run as fast as possible (  = f m /f) 1 1

23. One Processor with Overhead Time and instruction overhead can be modeled by: K = K w + K o And processor utilization splits into:  =  w +  0 Current consumption with overhead can be modeled by: I s = F(f,  ) = F(f,  w +  0 )

24. Reduce Overhead by Frequency Scaling Example:  w = 0.5,  o = 0.1, f = 4MHz, I A = 20mA, a I =2.0×10 -8, a A = 4.0×10 -8 c < 2.25  f ’ = cf < 9MHz f I I active I Idle

25. Questions about Frequency Scaling Exactly how much should we scale the frequency? What might change if we scale the frequency?

26. Roadmap

27. Multiple Processors Two fundamental questions: 1.How to partition the application tasks? 2.What are the inter-processor communication costs?

28. Application Partition Bit-level 57% Byte-level 28% Other network processing Other non-network CPU time 10% 5% Split off the bit-level processing Split off the whole network stack Is it beneficial? What is the gain? Cut off 45 cycles But add additional 130 cycles Solution: Rewrite the structure of Component

29. Inter-Processor Communication Cost How do we measure it? What factors may affect it?

30. Multiple Processor Mathematical Model Now, we have two variables: N,  We have only one variable 

31. Frequency Scaling Scale frequency by 1/N: We got:

32. Frequency Scaling pIIpII pIIpII pIIpII Which means frequency scaling alone consumes more energy!!! Why? b I > 0, b A > 0,  > 0, N > 1  I s – I m < 0 Example: b I =2.0×10 -8, b A = 4.0×10 -8,  = 0.5, N = 3 I s – I m = -8×10 -8 < 0  p = 

33. Reduction of Frequency and Overhead Example:  w = 0.5,  o = 0.1, I A (f) = 20mA, b I =2.0×10 -8, b A = 4.0×10 -8 N < 5,001 If we can both reduce frequency and eliminate overhead Question: what is the optimal N? pIIpII pIIpII pIIpII  p =  w

34. Share Idle Current I Question: How difficult is it? III I

35. Conclusions Single Processor: There is an optimal frequency for a given task load Multiple Processor: Simple task partition and frequency scaling wouldn’t save any energy. We can save power in a multiple processor design if we can eliminate various types of overhead. Big direction: The optimal architecture should build upon a single processor with hardware support for multiple contexts.

36. About the result What do you think about the results? Results are very convincing and useful? Not quite convincing, limited usefulness? One Processor: Task load may vary, not a constant. Multiple Processor: 1.Limited experiment data. 2.Some assumptions that are difficult to achieve. Big design direction: not quite convincing

37. Roadmap

38. Summary - Contributions Developed useful mathematical models of energy consumption for single and multiple processors. Explored the tradeoffs between simple and multiple processor Observed that Mere partition or simple frequency scaling does not save energy in multiple processors system. Proved that it is possible to save energy in a multiple processor system via elimination of various types of overhead. Pointed out the direction of future architecture design for WSN

39. Summary - Limitations Limited experiments Mathematical model can be refined Some assumptions difficult to achieve Results have limited usefulness Did not consider group behavior

40. Roadmap

41. Related Work Shin and Choi: real-time scheduler Lorch and Smith: Survey of techniques for lowering power on portable computers Henkel: hardware-software partition Kirovski and Potkonjak: task partition

42. References [1] Jason Hill, et al. “System Architecture Directions for Networked Sensors” [2] John A. Stankovic, et al. “Real-Time Communication and Coordination in Embedded Sensor Networks” [3] Shin and Choi “Power conscious fixed priority scheduling for hard real-time systems” [4] J. Lorch and A. Smith “Software Strategies for Portable Computer Energy Management” [5] J. Henkel. “A low power hardware/software partitioning approach for core-based embedded systems” [6] D. Kirovski and M. Potkonjak. “System-level synthesis of low- power hard real-time systems” [7] Radu Stoleru: Presentation - HW1