Cellular’Networks’and’Mobile’ Compung’ COMS’6998

Cellular Networks and Mobile Compu5ng COMS 6998-‐8, Spring 2012

Instructor: Li Erran Li ([email protected])

hLp://www.cs.columbia.edu/~coms6998-‐8/ 4/2/2012: Mobile Cloud Compu5ng

4/2/12 Cellular Networks and Mobile Compu5ng (COMS 6998-‐8) 1

Mobile Cloud Compu5ng (mCloud) today

•  Apple iCloud – Store content in cloud and sync to all registered devices

– Hosted by Windows Azure and Amazon AWS

–  iCloud Storage APIs support third-‐party app document syncing

2 4/2/12 Cellular Networks and Mobile Compu5ng (COMS 6998-‐8)

Mobile Cloud Compu5ng today (Cont’d)

•  Amazon Silk browser – Accelerates web access – Learns user behavior and precache

–  Intelligently par55on work between local and Amazon cloud


mCloud Fundamental Challenges

•  What architecture best supports mCloud? •  What programming model best enables client to tap mCloud resources?

•  What are basic services or building blocks for mCloud?

•  What best supports service interac5on?


mCloud Architecture •  Resource-‐intensive mobile

applica5ons –  Face recogni5on for social networking app

–  Gesture recogni5on for control media app

–  Object and post recogni5on for augmented reality app

•  End-‐to-‐end latency and througput maLers for crisp interac5on –  Augmented reality need to display results within 1 sec

–  Need high data rate processing capability, low frame rate can miss gesture

5

Delay, loss on frame rate of video stream transfer [Odessa, 2011]

4/2/12 Cellular Networks and Mobile Compu5ng (COMS 6998-‐8)

mCloud Architecture (Cont’d) •  WAN performance

–  First hop latency in 3G is 200ms

–  Verizon LTE :128ms, 6.44 Mbps downlink, 5Mbps uplink [Pcworld, March 2011]

•  There is a need for a middle 5er

•  cloudlet = (compute cluster + wireless access point + wired Internet access + no baLery limita5ons)

•  → “data center in a box” 6

“Anatomizing Applica5on Performance Differences on Smartphones”, MobiSys 2010 (Huang et al)


mCloud Architecture (Cont’d)

•  Cloudlet possible loca5ons •  Cellular providers has a unique advantage

7

BS

Wireless Core

Internet

WiFi AP

RDCA1

RDCA2

RDCB1

RDCB2

Regional Data centers (RDC)

RNC

Storage nodes

Compute nodes

Possible locations of cloudlet


mCloud Programming Model •  MAUI: RPC based offloading architecture •  CloneCloud: 5ght synchroniza5on between cloud and

phone •  Odessa: data-‐flow graph to exploit parallelism in

percep5on applica5ons •  Orelans: a new programming model based on grains •  MAUI, CloneCloud , Odessa all have profiler, solver

8

MAUI CloneCloud Odessa Orleans

Remote execu5on unit

Methods (RMI)

Threads Tasks Grains


mCloud Programming Model: MAUI

•  Combine extensive profiling with an ILP solver –  Makes dynamic offload decisions –  Op5mize for energy reduc5on –  Profile: device, network, applica5on

•  Leverage modern language run5me (.NET CLR) –  Portability:

•  Mobile (ARM) vs Server (x86) •  .NET Framework Common Intermediate Language

–  Type-‐Safety and Serializa5on: •  Automate state extrac5on

–  Reflec5on: •  Iden5fies methods with [Remoteable] tag •  Automates genera5on of RPC stubs


Maui server Smartphone

Applica5on

Client Proxy

Profiler

Solver

Maui Run5me

Server Proxy

Profiler

Solver

Maui Run5me

Applica5on

RPC

RPC

Maui Controller

mCloud Programming Model: MAUI (Cont’d)

Intercepts Applica5on Calls Synchronizes State

Chooses local or remote

Handles Errors

Provides run5me informa5on

•  MAUI architecture

4/2/12 Cellular Networks and Mobile Compu5ng (COMS 6998-‐8) 10 Source: MAUI Mobisys presenta5on

MAUI Profiler

Profiler Callgraph

Execu5on Time

State size

Network Latency

Network Bandwidth

Device Profile CPU Cycles

Network Power Cost Network Delay Computa5onal Delay

Computa5onal Power Cost Computa5onal Delay

Annotated Callgraph

Source: MAUI Mobisys presenta5on 4/2/12 Cellular Networks and Mobile Compu5ng

(COMS 6998-‐8) 11

MAUI Solver

B

900 mJ 15ms

C 5000 mJ 3000 ms

1000mJ 25000 m

J D 15000 mJ 12000 ms

10000 mJ

A

Computa5on energy and delay for execu5on

Energy and delay for state transfer

A sample callgraph

Source: MAUI Mobisys presenta5on


12

Is Global Program Analysis Needed?

FindMatch 900 mJ

Ini7alizeFace Recognizer 5000 mJ

1000mJ 25000 m

J DetectAndExtract Faces

15000 mJ

10000 mJ

User

Interface

Yes! – This simple example from Face Recogni5on app shows why local analysis fails.

Cheaper to do local




FindMatch 900 mJ

Ini7alizeFace Recognizer 5000 mJ

1000mJ 25000 m

J DetectAndExtract Faces

15000 mJ

10000 mJ

User

Interface

Yes! – This simple example from Face Recogni5on app shows why local analysis fails.

Cheaper to do local

Cheaper to do local




FindMatch

Ini7alizeFace Recognizer

1000mJ

DetectAndExtract Faces

User

Interface

25900mJ Cheaper to offload



15

Can MAUI Adapt to Changing Condi5ons?

•  Adapt to: – Network Bandwidth/Latency Changes – Variability on method’s computa5onal requirements

•  Experiment: – Modified off the shelf arcade game applica5on – Physics Modeling (homing missiles) – Evaluated under different latency seungs


(COMS 6998-‐8) 16

DoLevel

HandleMissiles

DoFrame

HandleEnemies

HandleBonuses 11KB + missiles

11KB +

missiles

*Missiles take around 60 bytes each

11KB + missiles

Required state is smaller

Complexity increases with # of missiles

Can MAUI Adapt to Changing Condi5ons?



17

Case 1

DoLevel

HandleMissiles

DoFrame

HandleEnemies

HandleBonuses


¡  Zero Missiles ¡  Low latency (RTT < 10ms)

Computa5on cost is close to zero

Offload star5ng at DoLevel


4/2/12 Cellular Networks and Mobile Compu5ng

(COMS 6998-‐8) 18

Case 2

DoLevel

HandleMissiles

DoFrame

HandleEnemies

HandleBonuses


¡  5 Missiles ¡  Some latency (RTT = 50ms)

Most of the computa5on cost

Very expensive to offload everything

LiLle state to offload

Only offload Handle Missiles


(COMS 6998-‐8) 19

MAUI Implementa5on •  Pla{orm

– Windows Mobile 6.5 –  .NET Framework 3.5 – HTC Fuze Smartphone – Monsoon power monitor

•  Applica5ons –  Chess –  Face Recogni5on – Arcade Game –  Voice-‐based translator

Source: MAUI Mobisys presenta5on 4/2/12 Cellular Networks and Mobile Compu5ng (COMS 6998-‐8) 20

Ques5ons

•  How much can MAUI reduce energy consump5on? •  How much can MAUI improve performance? •  Can MAUI Run Resource-‐Intensive Applica5ons?


0

5

10

15

20

25

30

35

Energy (Jou

les)

Smartphone only MAUI (Wi-‐Fi, 10ms RTT) MAUI (Wi-‐Fi, 25ms RTT) MAUI (Wi-‐Fi, 50ms RTT) MAUI (Wi-‐Fi, 100ms RTT)

How much can MAUI reduce energy consump5on?

Big savings even on 3G An order of magnitude improvement on Wi-‐Fi

Face Recognizer


How much can MAUI improve performance?

0

3,000

6,000

9,000

12,000

15,000

18,000

21,000

ExecuC

on DuraC

on (m

s)

Smartphone only MAUI (Wi-‐Fi, 10ms RTT) MAUI (Wi-‐Fi, 25ms RTT) MAUI (Wi-‐Fi, 50ms RTT) MAUI (Wi-‐Fi, 100ms RTT) MAUI* (3G, 220ms RTT)

Improvement of around an order of magnitude

Face Recognizer

Source: MAUI presenta5on 4/2/12 Cellular Networks and Mobile Compu5ng (COMS 6998-‐8) 23

Latency to server impacts the opportuni5es for fine-‐grained offload

0

20

40

60

Energy (Jou

les)

Smartphone only

MAUI (Wi-‐Fi, 10ms RTT) MAUI (Wi-‐Fi, 25ms RTT)

Up to 40% energy savings on Wi-‐Fi

Solver would decide not to offload Arcade Game


Can MAUI Run Resource-‐Intensive Applica5ons?

0 10 20 30 40 50 60 70 80 90

100

00:00 00:43 01:26 02:10 02:53

CPU Con

sumpC

on (%

)

Time

CPU1

CPU2

CPU Intensive even on a Core 2 Duo PC

Can be run on the phone with MAUI

Translator


Conclusions

•  MAUI enables developers to: –  Bypass the resource limita5ons of handheld devices –  Low barrier entry: simple program annota5ons

•  For a resource-‐intensive applica5on –  MAUI reduced energy consumed by an order of magnitude –  MAUI improved applica5on performance similarly

•  MAUI adapts to: –  Changing network condi5ons –  Changing applica5ons CPU demands


mCloud Programming Model: CloneCloud

•  Offloading decision done at beginning of execu5on


The Before-‐A~er Picture

Phone

UI W

Phone

Clone

Cloud

WUI W'

Clone

Clone

Clone

4/2/12 Cellular Networks and Mobile Compu5ng (COMS 6998-‐8) 28 Courtesy: Byung-‐Gon Chun et. al.

CloneCloud v1 Architecture

VMMHW

PartitionAnalyzer

OSVirtual HW

Migration

Mobile Device

Runtime

OSHW

Application

App.VM

Man

ager Migration

Clone VM

ProfilerOS

Virtual HW

Application

App.VM

ManagerProfiler


AppVM Clones

•  Virtual machine of en5re client device – Android x86 VM na5vely executed on VMWare in an x86 machine

•  Synchronized file systems


Par55oning

Where to par77on code, sa7sfying any constraints for correctness, so as to op7mize for current condi7ons


Automa5c Par55oning Framework

Partition Analyzer

Application binary

Partitioning constraints

Static analysis

location- constraints

Profiling inputs

Dynamic profiling

cost-annotated executions

Optimization solver

Optimal partitioning

points

Identify valid split points

Construct cost models

Pick best choice for an objective


Par55oning: Sta5c Analysis •  Par55oning points

–  Restrict to method entry/exit

•  Iden5fy “pinned” methods –  Iden5fy framework library methods

•  Iden5fy mutually dependent na5ve state –  Class na5ves stay together

•  Collect sta5c control flow – Who calls whom


Par55oning: Profiling

•  Pick k invoca5ons •  For each invoca5on

–  Run app on mobile device

–  Run app on clone •  For each method

–  Execu5on 5me –  Context size entry/exit –  Es5mate of energy consump5on

a30, 2100

c60, 810

a'11, 1200

main

main'19, 9

5

b50, 5900

a


Par55oning: Intui5on

•  Par55oning points splice profile trees together •  Context size used to es5mate network cost

a30, 2100

c60, 810

a'11, 1200

main

main'19, 9

5

b50, 5900

a a

ca'

main

main'

b50, 520

a

MobileDevice Clone


Par55oning: Op5miza5on

•  List all par55oning choices

•  Remove par55oning choices that do not meet the constraints

•  For each choice, compute total 5me

•  Find the minimum


Distributed Execu5on

How to seamlessly execute the par77ons of an applica7on locally and remotely


Migra5on Architecture

App-VM

Migrator

NodeManager

NodeManagerNet

(1) (4)

Mobile Device Clone

Partitions

App-VM

Application

Migrator

App-VM

Migrator

Application

App-VM

Migrator

Clone

App-VM

Migrator

Clone

App-VM

Migrator

(2)

(3)


Migra5on: Suspend-‐Transmit-‐Resume

Mobile device Clone

Transmit

At migration point Suspend thread Capture context Transmit Launch process

Patch migrated context Resume thread

Suspend thread Capture context Merge migrated

context Resume thread

At reintegration point


Migra5on Challenges

•  Regular IDs (references) not globally unique – Address space difference between mobile device and clone

•  System objects created at boot everywhere


Migra5on: References in Mo5on

(1) Mobile Device

Reference MID CID0x01 1 null0x02 2 null0x03 3 null

migration

New objects

GC’ed

(2) Clone

Reference MID CID0x21 1 110x22 2 120x23 3 130x24 null 140x22 null 15

reintegration

(3) Mobile DeviceReference MID CID0x01 1 110x02 2 120x03 3 130x04 4 140x05 5 15


The CloneCloud v1 Prototype

•  On Android pla{orm + x86 VM clones •  Modified DalvikVM to support thread-‐level migra5on and dynamic profiling

•  Implemented NodeManager to handle registra5on and communica5on

•  Sta5c analysis using JChord


Evalua5on Setup

•  Test applica5ons –  Image search –  Virus scanning –  Privacy-‐preserving user profiling

•  Phone: Android Dev Phone 1 •  Clone VM: a server with a 3.0GHz Xeon CPU running VMWare ESX 4.1 in Intel IT infrastructures

•  Wireless connec5on: WiFi, T-‐mobile 3G


Execu5on Time Comparison (Image Search)

Exe

cutio

n tim

e (s

econ

ds)

0

500

1000

1500

2000

2500

1 image 10 images 100 images

Phone(Local)

CloneCloud(Wi-‐Fi)

CloneCloud(3G)

20x

1x


Energy Consump5on Comparison (Image Search)

Ene

rgy

cons

umpt

ion

(J)

0

300

600

900

1200

1500

1800

1 image 10 images 100 images

Phone(Local)

CloneCloud(Wi-‐Fi)

CloneCloud(3G)

20x

1x


Discussion

•  Applicability is applica5on-‐specific – Applica5on characteris5cs – Execu5on mechanism

•  A design point with focus on automa5on – Apps structured to be more amenable to migra5on

•  Clone VMs in untrusted environments


Conclusion

•  CloneCloud: automa5c par55oning and migra5on to enhance mobile applica5ons – Use of clones – Flexible app par55oning – Seamless migra5on

Lots of excitements in mobile cloud computing


mCloud Programming Model: Odessa •  Data flow graph: ver5ces are stages; edges are connectors;

stages share nothing

48 Face RecogniCon Gesture RecogniCon 4/2/12 Cellular Networks and Mobile Compu5ng (COMS 6998-‐8) Object Pose EsCmaCon

Source: Odessa Mobisys presenta5on

mCloud Programming Model: Odessa (Cont’d)

•  Offloading DEcision System for Streaming Applica5ons

Network Applica5on

Sprout

Odessa

Mobile Device

Applica5on

Sprout Odessa Profiler

Cloud Infrastructure

Odessa Run5me Profiler Decision

Engine


(COMS 6998-‐8) 49 Source: Odessa Mobisys presenta5on

mCloud Programming Model: Odessa (Cont’d)

50

B2

Network

C B A

B1 A

Applica.on Data Flow Graph Screen

C

Local Execu5on

Cost

Remote Execu5on

Cost > 4/2/12 Cellular Networks and Mobile Compu5ng (COMS 6998-‐8) Smartphone

Cloud Infrastructure

Incremental decisions adapt quickly to input and pla{orm variability.

Source: Odessa Mobisys presenta5on

mCloud Programming Model: Orleans

51

•  So~ware framework and run5me to make cloud programming easier and more produc5ve

•  Shi~ burden of correctness and performance from developer to Orleans system

•  Experimental system from Microso~ Research

•  Radically simplified, prescrip5ve programming model –  Actors –  Asynchronous messaging –  Lightweight transac5ons –  Persistence –  Adap5ve performance

management

Applica5on

Orleans

.NET

Azure

Servers


mCloud Programming Model: Orleans (Cont’d)

•  Actor based: fine-‐grain distributed objects are natural abstrac5on

•  Grains par55on data •  Secure and isolated computa5on with clear points of communica5ons – Enable computa5on replica5on

•  Natural integra5on with persistent storage – Grain resides on disk un5l ac5vated

52


mCloud Programming Model: Orleans (Cont’d)

53

Field Value

Name “John Doe”

Email “[email protected]”

Address “123 Main St., Anywhere UR 01234”

Products

Grain ID1 Grain

ID2

Checkout AddProduct RemoveProduct

Grain (actor)

Customer Grain Messages

State

Methods Message Queue


(COMS 6998-‐8) Courtesy Jim Larus

Support for Service Interac5on

•  Synergy of mCloud services – Shared basic services enables more efficient usage of cloud resources(e.g. shared memcache eliminates data duplica5on of individual services)

– Co-‐loca5on makes mashed-‐up applica5ons to achieve na5ve performance (file transfer becomes an object reference)

•  mCloud offers shared pla{orm services •  mCloud op5mizes service interac5on through ac5ve VM migra5on


Closing Thoughts

•  Cloud compu5ng needs to advance in architecture, programming model, pla{orm services to revolu5onize mobile compu5ng


Useful Tools

•  Hprof: a heap/CPU profiling tool •  Jchord: a sta5c analysis tool on Java bytecode •  Dummynet (ipfw): simulates/enforces queue and bandwidth limita5ons, delays, packet losses

•  OpenCV: a library of programming func5ons for real 5me computer vision


Cellular’Networks’and’Mobile’ Compung’ COMS’6998

Documents

Transcript of Cellular’Networks’and’Mobile’ Compung’ COMS’6998