Dynamic Resource Allocation and Parallel Execution in Cloud for Mobile Code Offloadings
THINKAIR: DYNAMIC RESOURCE
ALLOCATION AND PARALLEL
EXECUTION IN CLOUD FOR MOBILE
CODE OFFLOADING
S. Kosta, A. Aucinas, P. Hui, R. Mortier, X. Zhang
INFOCOM ‘12
Outline
•
Introduction
•
Design and Architecture
•
Profiling
•
Evaluation
•
Summary
Introduction
•
Smartphone applications are more and more complex
•
Smartphone users have to continually upgrade their
hardware but still experience short battery lifetime.
•
ThinkAir provide an execution offloading infrastructure
and resource consumption profilers.
•
It also provides library, compiler, VM manager and parallel
processing module in cloud.
Related work
•
MAUI [MobiSys ’10]
[1]
work does not address the scaling of execution in
cloud.
•
CloneCloud [EuroSys ’11]
[2]
only considers limited input/environmental
conditions in the offline pre-processing to determine which parts should
be migrated on the cloud.
•
Virtual Smartphone [WoWMoM ‘10]
[3]
uses Android x86 to execute
Android images but does not provide any programmer support.
•
Existing work does not provide any mechanism to support on-demand
resource allocation.
[1] MAUI: making smartphones last longer with code offload. (Duke)
[2] Clonecloud: Elastic execution between mobile device and cloud. (intel researsh)
[3] Virtual smartphone over IP. (NTT)
Design objectives
•
Dynamic adaptation to changing environments
•
Ease of use for developers
•
Providing a simple interface.
•
Performance improvement through cloud computing
•
Dynamic scaling of computational power
•
Dynamically scaling the computational power at the server side as
well as parallelizing execution
Design for compilation
•
Programmer API
•
ThinkAir provides a simple library and compiler support.
•
Any method to be considered for offloading is annotated with
@Remote.
•
Compiler
•
Remoteable Code Generator : translates the annotated codes.
•
Customized Native Development Kit : provide some native code
on
the phone (arm base)
can be supported on the cloud (x86 base).
Design for execution
•
Execution Controller
•
The Execution Controller drives the execution of remoteable
methods.
•
Decides whether to offload execution of a method.
•
The decides depends on the current environment as well as that
learnt from past executions.
•
User can also set a policy according to their needs
•
E
x
e
c
u
t
i
o
n
t
i
m
e
•
E
n
e
r
g
y
•
E
x
e
c
u
t
i
o
n
t
i
m
e
a
n
d
e
n
e
r
g
y
•
E
x
e
c
u
t
i
o
n
t
i
m
e
,
e
n
e
r
g
y
a
n
d
c
o
s
t
Design for execution
•
Exception handle
•
If the connection fails during remote execution, goes back to the
local execution and discard the profile and the Execution Controller
initiates asynchronous reconnection to the server.
•
If an exception is thrown during the remote execution of the method,
it is passed back in the execution results and re-thrown on the
phone
Design for application server
•
Client Handler
•
Communication protocol, managing connections from clients,
receiving and executing offloaded code, and returning results.
•
The remoteable method is called using Java reflection and the
result or exception is sent back to client.
•
In case of OutOfMemoryError, the Client Handler does not send it
back to the client directly, it try to execute the method on a more
powerful clone.
•
Client Handler also sends profiling data for future offloading
decisions.
Design for application server
•
Cloud Infrastructure
•
Build a customized version of Android x86, leaving out
unnecessary components and running on VirtualBox.
•
There are 6 types of VMs with different configurations of CPU and
memory.
Profiling
•
ThinkAir includes three profilers (hardware, software, and
network), which collect variant data and feed into the energy
estimation model.
•
Use Android intents to keep track of important environmental
parameters (battery levels, data connectivity and connection
types).
•
Hardware Profiler
•
C
P
U
:
T
h
e
C
P
U
s
t
a
t
e
i
s
i
d
l
e
o
r
h
a
v
e
a
u
t
i
l
i
z
a
t
i
o
n
f
r
o
m
1
–
1
0
0
%
•
S
c
r
e
e
n
:
T
h
e
L
C
D
s
c
r
e
e
b
r
i
g
h
t
n
e
s
s
l
e
v
e
l
b
e
t
w
e
e
n
0
–
2
5
5
.
•
W
i
F
i
:
T
h
e
p
o
w
e
r
s
t
a
t
e
o
f
W
i
F
i
i
n
t
e
r
f
a
c
e
i
s
l
o
w
o
r
h
i
g
h
.
•
3
G
:
T
h
e
3
G
r
a
d
i
o
c
a
n
b
e
e
i
t
h
e
r
i
d
l
e
,
o
r
i
n
u
s
e
w
i
t
h
a
s
h
a
r
e
d
o
r
d
e
d
i
c
a
t
e
d
c
h
a
n
n
e
l
.
Profiling
•
Software Profiler
•
Software Profiler uses the standard Android Debug API to record
the following information.
•
Overall execution time of the method
•
Thread CPU time of the method
•
Number of instructions executed
•
Number of method calls
•
Thread memory allocation size
•
Garbage Collector invocation count, both for the current thread and
globally.
Profiling
•
Network Profiler
•
Account many different sets of parameters, by combining both
intent and instrumentation-based profiling.
•
Tracks several other parameters, including the number of packets
transmitted and received per second, uplink channel rate and
uplink data rate for the WiFi interface, and receiving and
transmitting data rate for the 3G interface.
•
Energy Estimation Model
•
Use a modified the original PowerTutor
[1]
model.
•
The maximum error is 6.27%.
[1]
http://ziyang.eecs.umich.edu/projects/powertutor/
Evaluation
•
Consider four complete benchmark applications : a solver
for the classic N-Queens problem, a face detection
application, a virus scanning application, and an
application combining two pictures into an unique large
one.
•
Run the experiments under four different connectivity
scenarios as follows.
•
P
h
o
n
e
:
E
e
x
e
c
u
t
e
d
o
n
t
h
e
p
h
o
n
e
.
•
W
i
F
i
-
L
o
c
a
l
:
D
i
r
e
c
t
l
y
c
o
n
n
e
c
t
s
t
o
a
W
i
F
i
r
o
u
t
e
r
a
t
t
a
c
h
e
d
t
o
t
h
e
c
l
o
u
d
s
e
r
v
e
r
v
i
a
W
i
F
i
l
i
n
k
.
•
W
i
F
i
-
I
n
t
e
r
n
e
t
:
C
o
n
n
e
c
t
s
t
o
t
h
e
c
l
o
u
d
s
e
r
v
e
r
u
s
i
n
g
a
n
o
r
m
a
l
W
i
F
i
a
c
c
e
s
s
p
o
i
n
t
v
i
a
t
h
e
I
n
t
e
r
n
e
t
.
•
3
G
:
C
o
n
n
e
c
t
e
d
t
o
t
h
e
c
l
o
u
d
u
s
i
n
g
3
G
d
a
t
a
n
e
t
w
o
r
k
.
N-Queens puzzle
•
Implement the algorithm to find all solutions for the N-
Queens Puzzle and return the number of solutions found.
•
When N > 5, offloading to cloud is more efficient than
executing on phone.
•
WiFi Local is the most efficient offloading method.
Face detection
•
A simple face detection program that counts the number
of faces in a picture.
•
When detect multiple picture, offloading to cloud is more
efficient than executing on phone.
Virus scanning
•
A virus detection algorithm for Android, which takes a
database of 1000 virus signatures.
•
The number of files is around 3,500.
•
Because of the large data transfer, they only consider
communication energy consumption.
Parallelization with multiple VM clones
•
The modular architecture of the ThinkAir framework
allows programmers to implement many parallel
algorithms with no modification to the ThinkAir code.
Parallelization with multiple VM clones
•
8-Queen puzzle
•
The problem is split by allocating different regions of the board to
different clones
•
The 4-clone case has the most performance benefits.
Parallelization with multiple VM clones
•
Face detection
•
The100 photos are distributed among the secondary for detection.
•
The 4-clone case has the most performance benefits.
Parallelization with multiple VM clones
•
Virus Scanning
•
The files to be scanned are distributed among the clones.
•
The 4-clone case has the most performance benefits.
Summary
•
ThinkAir, a framework for offloading mobile computation
to the cloud.
•
ThinkAir requires only simple modifications to an
application’s source code coupled with use ThinkAir tool-
chain.
•
They are continuing the development of several key
components of ThinkAir : port Android to Xen allowing it to
be run on commercial cloud, and continue to work on
improving programmer support for parallelizable
applications.
This study explores dynamic resource allocation and parallel execution in the cloud environment optimized for mobile code offloading scenarios. The research, presented at INFOCOM '12 by Kosta, Aucinas, Hui, Mortier, and Zhang, delves into the efficient utilization of resources in a cloud-based system to enhance mobile application performance by offloading tasks to cloud servers. The innovative approach of dynamic resource allocation enables parallel execution, ensuring optimal performance and scalability for mobile devices. The findings contribute to the advancement of cloud computing strategies for mobile applications.
Uploaded on Feb 16, 2025 | 1 Views
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
THINKAIR: DYNAMIC RESOURCE ALLOCATION AND PARALLEL EXECUTION IN CLOUD FOR MOBILE CODE OFFLOADING S. Kosta, A. Aucinas, P. Hui, R. Mortier, X. Zhang INFOCOM 12
Outline Introduction Design and Architecture Profiling Evaluation Summary
Introduction Smartphone applications are more and more complex Smartphone users have to continually upgrade their hardware but still experience short battery lifetime. ThinkAir provide an execution offloading infrastructure and resource consumption profilers. It also provides library, compiler, VM manager and parallel processing module in cloud.
Related work MAUI [MobiSys 10][1] work does not address the scaling of execution in cloud. CloneCloud [EuroSys 11] [2] only considers limited input/environmental conditions in the offline pre-processing to determine which parts should be migrated on the cloud. Virtual Smartphone [WoWMoM 10][3] uses Android x86 to execute Android images but does not provide any programmer support. Existing work does not provide any mechanism to support on-demand resource allocation. [1] MAUI: making smartphones last longer with code offload. (Duke) [2] Clonecloud: Elastic execution between mobile device and cloud. (intel researsh) [3] Virtual smartphone over IP. (NTT)
Design objectives Dynamic adaptation to changing environments Ease of use for developers Providing a simple interface. Performance improvement through cloud computing Dynamic scaling of computational power Dynamically scaling the computational power at the server side as well as parallelizing execution
Design for compilation Programmer API ThinkAir provides a simple library and compiler support. Any method to be considered for offloading is annotated with @Remote. Compiler Remoteable Code Generator : translates the annotated codes. Customized Native Development Kit : provide some native code on the phone (arm base) can be supported on the cloud (x86 base).
Design for execution Execution Controller The Execution Controller drives the execution of remoteable methods. Decides whether to offload execution of a method. The decides depends on the current environment as well as that learnt from past executions. User can also set a policy according to their needs Execution time Energy Execution time and energy Execution time, energy and cost
Design for execution Exception handle If the connection fails during remote execution, goes back to the local execution and discard the profile and the Execution Controller initiates asynchronous reconnection to the server. If an exception is thrown during the remote execution of the method, it is passed back in the execution results and re-thrown on the phone
Design for application server Client Handler Communication protocol, managing connections from clients, receiving and executing offloaded code, and returning results. The remoteable method is called using Java reflection and the result or exception is sent back to client. In case of OutOfMemoryError, the Client Handler does not send it back to the client directly, it try to execute the method on a more powerful clone. Client Handler also sends profiling data for future offloading decisions.
Design for application server Cloud Infrastructure Build a customized version of Android x86, leaving out unnecessary components and running on VirtualBox. There are 6 types of VMs with different configurations of CPU and memory.
Profiling ThinkAir includes three profilers (hardware, software, and network), which collect variant data and feed into the energy estimation model. Use Android intents to keep track of important environmental parameters (battery levels, data connectivity and connection types). Hardware Profiler CPU : The CPU state is idle or have a utilization from 1 100% Screen : The LCD scree brightness level between 0 255. WiFi : The power state of WiFi interface is low or high. 3G : The 3G radio can be either idle, or in use with a shared or dedicated channel.
Profiling Software Profiler Software Profiler uses the standard Android Debug API to record the following information. Overall execution time of the method Thread CPU time of the method Number of instructions executed Number of method calls Thread memory allocation size Garbage Collector invocation count, both for the current thread and globally.
Profiling Network Profiler Account many different sets of parameters, by combining both intent and instrumentation-based profiling. Tracks several other parameters, including the number of packets transmitted and received per second, uplink channel rate and uplink data rate for the WiFi interface, and receiving and transmitting data rate for the 3G interface. Energy Estimation Model Use a modified the original PowerTutor [1] model. The maximum error is 6.27%. [1] http://ziyang.eecs.umich.edu/projects/powertutor/
Evaluation Consider four complete benchmark applications : a solver for the classic N-Queens problem, a face detection application, a virus scanning application, and an application combining two pictures into an unique large one. Run the experiments under four different connectivity scenarios as follows. Phone : Eexecuted on the phone. WiFi-Local : Directly connects to a WiFi router attached to the cloud server via WiFi link. WiFi-Internet : Connects to the cloud server using a normal WiFi access point via the Internet. 3G : Connected to the cloud using 3G data network.
N-Queens puzzle Implement the algorithm to find all solutions for the N- Queens Puzzle and return the number of solutions found. When N > 5, offloading to cloud is more efficient than executing on phone. WiFi Local is the most efficient offloading method.
Face detection A simple face detection program that counts the number of faces in a picture. When detect multiple picture, offloading to cloud is more efficient than executing on phone.
Virus scanning A virus detection algorithm for Android, which takes a database of 1000 virus signatures. The number of files is around 3,500. Because of the large data transfer, they only consider communication energy consumption.
Parallelization with multiple VM clones The modular architecture of the ThinkAir framework allows programmers to implement many parallel algorithms with no modification to the ThinkAir code.
Parallelization with multiple VM clones 8-Queen puzzle The problem is split by allocating different regions of the board to different clones The 4-clone case has the most performance benefits.
Parallelization with multiple VM clones Face detection The100 photos are distributed among the secondary for detection. The 4-clone case has the most performance benefits.
Parallelization with multiple VM clones Virus Scanning The files to be scanned are distributed among the clones. The 4-clone case has the most performance benefits.
Summary ThinkAir, a framework for offloading mobile computation to the cloud. ThinkAir requires only simple modifications to an application s source code coupled with use ThinkAir tool- chain. They are continuing the development of several key components of ThinkAir : port Android to Xen allowing it to be run on commercial cloud, and continue to work on improving programmer support for parallelizable applications.
