MAUI: Dynamically Splitting Apps Between the Smartphone and Cloud
Brad Karp
UCL Computer Science
CS M038 / GZ06 28th February 2012
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) Total power: 268.8 mW, i.e., 19 hours in idle mode on iPhone 4
Smartphone Backlight Power
Consumption
Smartphone CPU and RAM Power
Consumption
• Subset of SPEC benchmarks at two clock
rates
[Carroll, Heiser,
Smartphone WiFi and 2.5G Power
Consumption
• 15 MB wget download for WiFi
[Carroll, Heiser,
Smartphone WiFi and 2.5G Power
Consumption
• 15 MB wget download for WiFi
[Carroll, Heiser,
USENIX ATC 2010]
Radio power consumption dwarfs CPU power consumption: ca. 700 mW for WiFi vs. ca. 180 mW for worst-case CPU load
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
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
Central trade-off: offloading computation to cloud may save CPU energy on phone, but sending current state of app to cloud costs radio energy on phone
Energy Consumption for Code
Upload: 3G vs. WiFi
[HTC Fuze, 1340 mAh battery]
Energy Consumption for Code
Upload: 3G vs. WiFi
[HTC Fuze, 1340 mAh battery]
Network RTT plays significant role in power consumption; TCP’s throughput inversely proportional to RTT
Energy consumed roughly linear in RTT (see Fig. 2)
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
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
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
.NET supports serializing data into XML
MAUI phone sends serialized state over network to server
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
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
Estimating Size of State Transfers
Optimizing Energy Use:
Annotated Call Graph
• Vertices: method’s computational and energy
Optimizing Energy Use:
Annotated Call Graph
• Vertices: method’s computational and energy
costs
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
End-to-End Energy Savings:
Ideal Application
End-to-End Energy Savings:
Other Applications
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
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
multi-threaded apps
– If two threads share state, wouldn’t want to
offload one and run one locally
