MAUI: Dynamically Splitting Apps Between the Smartphone and Cloud

Transcription

1 MAUI: Dynamically Splitting Apps Between the Smartphone and Cloud Brad Karp UCL Computer Science CS M038 / GZ06 28 th February 2012

2 Limited Smartphone Battery Capacity iphone 4 battery: 1420 mah (@ 3.7 V) Idle state (backlight off) power costs for Openmoko Neo Freerunner smartphone: (note 2.5G radio) [Carroll, Heiser, USENIX ATC 2010] Total power: mw, i.e., 19 hours in idle mode on iphone 4 battery 2

3 Smartphone Backlight Power Consumption [Carroll, Heiser, USENIX ATC 2010] 3

4 Smartphone CPU and RAM Power Consumption [Carroll, Heiser, USENIX ATC 2010] Subset of SPEC benchmarks at two clock rates idle : no application running 4

5 Smartphone WiFi and 2.5G Power Consumption 15 MB wget download for WiFi [Carroll, Heiser, USENIX ATC 2010] 50 KB wget download for GPRS 5

6 Smartphone WiFi and 2.5G Power Consumption Radio power consumption dwarfs CPU power consumption: ca. 700 mw for WiFi vs. ca. 180 mw for worst-case CPU load 15 MB wget download for WiFi [Carroll, Heiser, USENIX ATC 2010] 50 KB wget download for GPRS 6

7 Central Idea: Offload Computation from Phone to Cloud Battery capacity on phones constraining (technology trends suggest will remain so) Phone compute resources limited (RAM, CPU, secondary storage) Cloud servers better provisioned Goals: Save energy on phone overall Improve (or do not reduce) app performance for user Minimize application changes 7

8 Central Idea: Offload Computation from Phone to Cloud Battery capacity on phones constraining (technology trends suggest will remain so) Phone compute resources limited (RAM, Central CPU, secondary trade-off: offloading storage) computation to cloud may save CPU energy on phone, but sending Cloud servers current state better of app provisioned to cloud costs radio Goals: energy on phone Save energy on phone overall Improve (or do not reduce) app performance for user Minimize application changes 8

9 Energy Consumption for Code Upload: 3G vs. WiFi [HTC Fuze, 1340 mah battery] 9

10 Energy Consumption for Code Upload: 3G vs. WiFi Network RTT plays significant role in power consumption; TCP s throughput inversely proportional to RTT Energy consumed roughly linear in RTT (see Fig. 2) Radio powered up during whole transfer [HTC Fuze, 1340 mah battery] 10

11 When Would Code Offload Save Energy? When state to transfer to cloud is small When CPU load for offloaded code is heavy When WiFi connectivity available with low RTT (i.e., server nearby) 11

12 MAUI: Architecture Overview 12

13 Offloading Code in MAUI CPU-independence provided by.net Common Language Runtime (CLR) Smartphone can send app code to server or code s hash to server (if code available from another server) Programmer marks methods that can be offloaded [Remoteable] in C# source code Default: local on phone only Avoid running UI code on server Avoid I/O with phone devices on server Avoid side effects outside app on server (why?) 13

14 Offloading Code in MAUI CPU-independence provided by.net Common Language Runtime (CLR) Smartphone can send app code to server or.net code s supports hash to serializing server (if data code into available XML from MAUI another phone server) sends serialized state over network to Programmer server marks methods that can be offloaded [Remoteable] in C# source code Default: local on phone only Avoid running UI code on server Avoid I/O with phone devices on server Avoid side effects outside app on server (why?) 14

15 Partitioning: Passing State Between Phone and Server Server will need all memory contents used by offloaded method No globals in C#, but public static member variables accessible by all methods State includes: method parameters all object s member variables deep copy of all heap-allocated data structures reachable from member variables 15

16 Handling Server Failures Phone enforces timeout on return of results by method invoked on server After timeout, phone may invoke method locally, or retry on other cloud server Risk: multiple executions of method on server(s) Hence, no side-effects outside app allowed on server! 16

17 Estimating Size of State Transfers Approximating state size reduces computational load of serialization 17

18 Optimizing Energy Use: Annotated Call Graph Vertices: method s computational and energy costs 18 Edges: state size and energy to transfer state

19 Optimizing Energy Use: Annotated Call Graph Insight: may be more power-efficient to offload multiple methods than one method Reason: want phone-cloud crossings to occur at edges of call graph with small state transfer Vertices: method s computational and energy costs 19 Edges: state size and energy to transfer state

20 End-to-End Energy Savings: Ideal Application Tiny state to ship to server; vast computation on server (even 3G wins!) 20

21 End-to-End Energy Savings: Other Applications Increased state transfer duration as RTT increases reduces energy savings 21

22 Offloaded Method Execution Performance Note latency measurements only for offloaded methods! For face recognition, nearly all work is in offloaded methods, so virtually end-to-end Not so for other two applications! 22

23 MAUI: For Discussion Goal is to minimize code modifications But code refactoring may improve performance Example: don t invoke server-side method 60 times/frame; invoke wrapper once/frame What is energy cost of profiling itself? Current system doesn t support multithreaded apps If two threads share state, wouldn t want to offload one and run one locally For apps like face recognition, is dynamic offload needed? Would HTTP POST do? 23