Triage: Balancing Energy and Quality of Service in a Microserver

1. Triage: Balancing Energy and Quality of Service in a Microserver Nilanjan Banerjee, Jacob Sorber, Mark Corner, Sami Rollins†, Deepak Ganesan University of Massachusetts, Amherst †University of San Francisco, San Francisco http://prisms.cs.umass.edu/hpm

2. Scenario : Deploying Remote Sensor Network • Imagine you want to deploy a large scale sensor network • What do you need ? • lot of sensors of course • also need powerful battery-powered server nodes • These nodes are traditionally called Microservers [Girod et al.] • What do these Microservers do ? • can be used for routing, query processing or storage • can act as a web server, information kiosk • can be used as a router

3. What does the Microserver Workload look like ? • Workload is often heterogeneous and sporadic • simple requests: store data, synchronize time • complex requests: return all images with >2 objects

4. Conflicting Goals : Performance and Energy ! • Microservers have high performance • highly responsive as a conventional server • provide performance guarantees to applications • should have a powerful CPU • should have lots of RAM • Remember that microservers are untethered and battery powered • they must be highly energy-efficient for longer lifetime • however, powerful platforms implies more energy consumption ! • How do we design microservers which balance performance and energy ! Energy Efficiency Microserver Performance

5. Possible Approaches 2.5 2 Power Consumed (mW) 1.5 1 0.5 0 50 100 150 200 250 300 350 400 450 500 Time (secs) • Use a single tiered powerful platform • use PSM and DVFS on the powerful platform • system suffers from the huge idle cost of the powerful tier

6. Possible Approaches 3 2.5 2 Power Consumed (W) 1.5 1 0.5 0 0 50 100 150 200 250 300 350 400 450 500 Time (secs) • Use a dual tier system(similar to Wake on Wireless [Shih et al.]) • tier-0 (Mote) as low power tier, tier-1 (Stargate) as a more powerful tier • keep Stargate in power down mode • wake Stargate whenever a task arrives at Mote • system suffers from a huge transition cost of Stargate

7. Our Approach : Triage 3 2.5 2 Power Consumed (W) 1.5 1 0.5 0 0 100 200 300 400 500 Time (sec) • Combine powerful platform (Stargate) and low power sensor (Mote) • Try to amortize transition costs by batching tasks at the sensor • The tasks arriving should meet soft real time deadlines • accurately profile execution time for tasks • wake the Stargate platform only for long batch of tasks • if possible execute simple tasks on the Mote

8. Outline • Design goals governing the Triage system • Overall Triage Architecture • Triage components • surrogates • profiler • scheduler • Triage Prototype • Experimental Setup and Evaluation • Related Work and Conclusions

9. Design Goals • Triage architecture should be general • applicable to microservers in wide variety of networks • Triage should be highly responsive to tasks • Triage should provide soft real time QoS guarantee • Triage should be highly energy efficient • maximize lifetime while meeting QoS guarantees • meet lifetime constraints while providing QoS guarantees

10. Triage Software Architecture • Tasks arrive at tier-0 (Mote), tier-1 (Stargate) is in low power mode • Surrogate services execute tasks or batch (log) them for Stargate • Profiler calculates the amount of energy and time taken by a task • Scheduler decides when to wake Stargate

11. Surrogates • Storage Surrogate • enables in-network storage applications • accepts reads, writes, and delete requests • request are either served from the cache or inserted into log • Query Processing Surrogate • provides query interface for data stored on the microserver • queries could be simple or complex • either queries are served from tier-0 or are inserted into log • Forwarding Surrogate • efficient routing using tier-0 and tier-1 network interfaces • determines which radio should be used to send the packet • if tier-0 radio is used, packet send immediately

12. Profiler • Measures the typical execution time and energy usage of tasks • measurements done through hardware assisted profiling • typical execution time : p % of the requests are likely to be satisfied • Online profiling involves two steps • task grouping – classify tasks based on the nature of task • parameter estimation • Parameter Estimation • is the probability distribution of time taken by task • and are the mean and variance of the distribution • applying Chebyschev’s inequality execution time of task is bounded by

13. Scheduler Uses information about tasks from the profiler Schedules tasks to minimise the number of Stargate wakeups We could use different scheduling algorithms under different scenarios the focus might be to meet maximum deadlines using minimum energy the aim make the batteries last for a 100 days Triage uses two example schedulers depending on optimization criterion deadline scheduler : meets maximum deadlines at minimum energy lifetime scheduler : satisfy lifetime constraint and meet max deadlines

14. Example Scheduler : Deadline Scheduler • Scheduler first queries the profiler for execution time for task • Algorithm then computes the Batch time (B ) • batch time at which Stargate can be woken up • all tasks and the new task meets its deadline • Let the new task be inserted at position of the sorted list • For each task , sets the latest start time • New Batch time is equal to B =B – L(Ti) • If B less than or equal to 0 tier-1 is woken up • else tier-1 wakeup timer fires after time B

15. Deadline Scheduler : Example • Let there be two batched tasks • TA: deadline=60 sec execution=3 sec • TB: deadline=64 sec execution=3 sec • L(TA) = 57 sec • L(TB) = 61 sec • B = 50 sec • New task TC arrives • TC: deadline=62 sec execution=3 sec • Task is inserted between TA and TB • Pushes task TAforward • New Batch time B = 48 sec

16. Example Scheduler : Lifetime Scheduler new tokens ? Tasks Battery Capacity Batch Taken Decide Wakeup of Tier-1 • Microserver generates tokens • rate of energy constraint • Calculate energy for present batch • If energy greater than tokens collected • do not wake the Stargate • Else wake Stargate to execute batch

17. Outline • Design goals governing the Triage system • Overall Triage Architecture • Triage components • surrogates • profiler • scheduler • Triage Prototype • Experimental Setup and Evaluation • Related Work and Conclusions

18. Triage Prototype

19. Evaluating Triage • Does Triage have power savings over other systems • single tiered system which uses PSM and DVFS (PSM-DVFS) • dual tier system based on the Wake-on-Wireless (WoW*) • dual tier system which used batching at tier-0 (Triage-Batch) • What benefit do tier-0 surrogates provide ? • How does the profiler perform ? • Do the scheduler algorithms meet their objective ? • What are the potential bottlenecks in the Triage system ?

20. Experimental Setup : Camera Sensor Network TelosB motes act as sensor cameras TelosB and laptop acts as client generating image requests for the microserver Client equipped with both 802.11b and 802.15.4 radios Power measurements taken using a NI-PCI 6251 DAQ

21. Profiler Performance 1200 Triage 1000 Triage-Batch 800 Average Power Consumed (mW) 600 400 200 0 100 150 200 250 300 Average Latency Constraint (sec) Images arrive at constant rate Queries arrive at a regular rate Triage consumes slightly more energy than a batching system

22. Profiler Performance 1 0.9 0.8 0.7 0.6 Triage Percentage of Deadlines met 0.5 Triage-Batch 0.4 0.3 0.2 0.1 0 100 150 200 250 300 Average Latency Constraint (sec) Triage system meets more than 90% of all the deadlines Triage-Batch meets less than 75% of the deadlines

23. Lifetime Scheduler Performance 100 Lifetime Constraint 90 Triage WoW* 80 PSM-DVFS 70 60 Battery Capacity Remaining (mAh) 50 40 30 20 10 0 0 10 20 30 40 50 60 Time (minutes) Initial battery capacity = 100 mAh , lifetime constraint = 1hr First 30 mins : tasks with long deadlines, 30-60 mins : tasks with short deadlines Triage meets the lifetime constraint WoW* and PSM-DVFS batteries die long before the deadline

24. System Bottlenecks 1200 TelosB Suspend 1000 Transition USB-Transfer Wifi+compute 800 Stargate-idle Average Power Consumed (mW) 600 400 200 0 Triage WoW* PSM-DVFS Triage leads to 300% improvement in battery lifetime The USB transfer energy is a huge bottleneck on Triage !

25. Related Work • Wake-On-Wireless [Shih et al.] • low-power radio receives wakeup messages • requires in-network support • focus on when to wake up • Wireless optimizations [Anand et al.] • Disk Spindown [Helmbold et al.] • Multiple radios [Pering et al.] • Multiple processor cores [Mayo & Ranganathan] • none provide orders-of-magnitude scaling of power • m-Platform [MSR06-142], LEAP [IPSN06] and LEAP2 • heterogenous stack-based sensor network platform • no intelligent profiling or scheduling to decide high power tier wakeups • Microserver platforms • throwboxes [infocom 07]

26. Conclusions • We presented Triage : a highly capable, energy efficient microserver • Triage uses Hierarchical Power Management • integrate multiple independent platforms • pass control between tiers • suspend unneeded tiers • Triage leads to 300% improvement in battery lifetime • Triage meets all lifetime goals and provides probabilistic QoS • Triage used for building highly energy efficient microservers • application in sensor deployment, mobile computing

27. Triage: Balancing Energy and Quality of Service in a Microserver Nilanjan Banerjee, Jacob Sorber, Mark Corner, Sami Rollins†, Deepak Ganesan University of Massachusetts, Amherst University of San Francisco, San Francisco http://prisms.cs.umass.edu/hpm