Mobile Computing - CSE Labs User Home Pages

mashpeemoveMobile - Wireless

Nov 24, 2013 (3 years and 11 months ago)

57 views

Tactics
-
Based Remote
Execution for Mobile
Computing

Presented by:
Pooja

Malani

Rajesh Krishna
Balan

et
al, MobiSys 2003

Motivation: handhelds are
weak!

O
Resource
-
poor mobile hardware

O
Rely
on finite energy
resources

O
Low performance

O
Computationally
-
intensive applications need

O
bounded
response time
.

O
high fidelity

O
m
aximum energy savings








Resource
heavy app

Resource
-

poor mobile
device

Solution: Cyber Foraging

O
“To live off the land”

need to
adapt

O
Use
resources in the environment to
augment
the computational and storage capabilities of
mobile devices

O
2
methods:
-


-

Data Staging


-

Remote Execution

Offloading Computation

Application Partitioning

MAUI

Tactics
-
based remote execution

VM Migration

CloneCloud


Research Prototype: Intel
Berkley (2011)


Fine grained execution
-

thread level granularity


Maximize energy
-
saving

+ VM encapsulates
potential relevant states on
a mobile device

+ no need to modify the
application

-

Large amount of data
transfer at runtime

-

Incurs high shipping
overhead

-

Not for applications that
rely on sensors on mobile
device



Research prototype
-

CMU
& Intel Research, PA
(2003)


Coarse grained execution


granularity of RPC
-


latency
-
fidelity metric

+ less offloading overhead

Tactics size smaller than
actual app code. Not much
data migrated during runtime

+ Immediately respond to
changing resources

+ parallel execution

-
Does not support multi
-
threaded execution

-

Not automated completely,
possible manual errors by the
developers


Research Prototype


Microsoft research (2010)


fine
-
grained
-

MAUI performs
method shipping with relevant
heap objects

+ Maximize energy
-
saving

+

less offloading overhead

+

performance improvements for
remote execution to servers that
are further away (RTT)

-

Large amount of data transfer
at runtime

-

programmers to identify and
mark code regions that can
potentially be offloaded.

-

Depends on correctness of the
programmer annotation

Remote execution methods

Key Insight :
For a large
number of applications
-




Number of useful remote
partition is small


Application developer
specifies these partitions


static partitioning


At runtime, the optimal
partition and its location is
selected


dynamic
partitioning



What is Tactics?

Concise
description of application’s
remote execution
capabilities

O

Only the useful remote partitions are
described

O

captured in a compact declarative form

O

each
tactic performs the required
operation

O
Two
-
fold
benefits of
tactics


1.
Enables powerful remote execution system

O
Provides
good application performance at runtime

O
Low
overhead

O

Automatic

2. Amenable to sound software engineering principles

O
Decrease the time needed to develop mobile applications for new

O
Easy
to use



Chroma
Tactics
-
based remote execution system

Assumptions

O
All code necessary for remote execution present on both
clients and servers

O
Individual remote calls are self contained and do not
produce side
effects

O
Existing applications only need to be slightly modified to
work with Chroma

Goals

O
Seamless from user perspective


Keep Secrets!

O
Effectiveness

O
Minimal burden on application developers


Keep it Simple

Requirements of Chroma

O
Ability to understand tactics descriptions


O
Mechanisms to determine the best tactic for the
available resources


Need to factor user preferences. Assume that this is provided
by external entity(utility functions)

Describing Tactics

APPLICATION

pangloss
-
lite
;


/*
RPC Specifications
*/

RPC
server_dict

(IN string line, OUT string
dict_out
);

RPC
server_ebmt

(IN string line, OUT string
ebmt_out
);

RPC
server_lm

(IN string
gloss_out
, IN string
dict_out
,




IN
string
ebmt_out
, OUT string translation
);


/*
Tactics (Useful Ways to Combine the RPCs) */

DEFINE_TACTIC
dict

=
server_dict

&
server_lm
;

DEFINE_TACTIC

ebmt

=
server_ebmt

&
server_lm
;

DEFINE_TACTIC

dict_ebmt

= (
server_dict
,
server_ebmt
)
&
server_lm
;



Tactics Semantics

Tactics support the following semantics

O

Specify RPCs that make up the tactics

O
Allow
RPCs to be executed in sequential order

O

Allow RPCs to be executed in
parallel


Useful for applications with multiple optional components E.g.,
language translation using different quality engines

O
Combination
of sequential and parallel
specifications

O
Tactic plan?

O

Specific server group specifications for any
RPC


Useful
for security or licensing
reason

Chroma Design: Main
Components

Applications Used

Three
real research
applications useful
for mobile
users


1.
Pangloss
-
Lite

is a natural language translator


Valuable
for travelers in foreign
countries


2.
Janus

is a speech
recognizer


Key
component of speech
interfaces


3.
Face

detects faces in
images


Representative
of surveillance applications

Experimental Platform

O
Remote servers &
f
ast client
:
HP
Omnibook

6000 notebooks


20 GB hard disk, 256 MB of memory


1 GHz
Pentium
3

O
Slow client
:
Thinkpad

560X Client


96 MB memory


200
Mhz

Pentium


Representative
of fastest
handhelds

O
100
Mb/s
Ethernet

O
Distributed file system
: Coda

O
Testing
methodology



Different inputs representing an operation



Each
result average of 20 runs



State of system reset before each run

Evaluation Objective

O
To show that Chroma has comparable performance
to an ideal runtime system


Ideal runtime system selects best tactic for current
environment


Ideal runtime system’s selection is determined offline while
Chroma selects online


O
Is the overhead of Chroma acceptable?


O
Use of extra servers


What additional performance benefits are possible?

Pangloss Lite: Tactics
Declaration

-
3 engines with different fidelities

-
150K lines of code ~ 7 tactics

-
52 tactic plans to choose from when 1 remote server is available

Pangloss
-
Lite: Result

-
latency
-
fidelity utility function to determine the tactic

-
3 unloaded remote servers used

-
Results off by 30%: incorrect resource estimation by Chroma


Janus: Tactics Declaration

-
Reduced fidelity 0.5, full fidelity 1

-
2 tactics

-
Tactics require 4 lines of code, Janus app ~ 120K lines of C code

Janus: Result

-
1 remote server used, both server & clients were unloaded

-
Slow client: differences due to experimental errors in latency measurements

Face: Tactics & Result

-
~ 20K lines of code in
Ada => 2 lines

-
1 unloaded server


Evaluation Objective

O
To show that Chroma has comparable performance
to an ideal runtime system


Ideal runtime system selects best tactic for current
environment


Ideal runtime system’s selection is determined offline while
Chroma selects online


O
Is the overhead of Chroma acceptable?


O
Use of extra servers


What additional performance benefits are possible?

Overhead of choosing a Tactic

-
Synthetic input

-
Slow client

-
Max overhead < 0.9ms


Overhead of Decision
Making: Pangloss
-
Lite

-
Pangloss
-
Lite: largest no. of tactic plans


atleast

52/ remote server

-
Longer on slower clients

-
Maximum overhead less than 0.5
secs


acceptable?!

Evaluation Objective

O
To show that Chroma has comparable performance
to an ideal runtime system


Ideal runtime system selects best tactic for current
environment


Ideal runtime system’s selection is determined offline while
Chroma selects online


O
Is the overhead of Chroma acceptable?


O
Use of extra servers


What additional performance benefits are possible?

Over Provisioned
Environments

O
Availability of compute servers varies widely in a
mobile environments

O
Performance improvements by opportunistically using
extra resources

O
Use slow clients

O
Introducing artificial load of 0.2

O
Use extra resources in three different ways

O
Fastest result

O
Data decomposition

O
Best fidelity


Hedging against load spikes

-
Using extra loaded servers to improve latency

-
Uncorrelated load


reduces latency

Data Decomposition

-
Improvement in Face Latency by Decomposition

-
Application to provide methods for splitting and
recombining the files

-
Allows Chroma to parallelize the operation


low latency

Meeting latency constraints

-
Achieving latency constraint(LC) for
Pangloss
-
Lite

-
Application to specify latency constraint for a given operation

-
Execute same operation on multiple servers(different fidelity)

-
When latency constraint expires, pick the one with best fidelity

-
LC 1 sec, sentence with 35 words, load 0.2, repeat 5 times

Conclusion

O
Chroma makes decision with regards to high level user preference.

O
Lampson’s hint “leave it to the client”

O
Tactics allow us to automatically use extra resources in the environment

O
Without modifying the application

O
Future challenges

O
Chroma does not take its own overhead into account. Acceptable?

O
Service discovery mechanisms?

O
Assume servers have been discovered and are able to handle any RPC call
(no code migration)

O
Chroma ignores battery lifetimes


O
Considers a fixed utility function

O
Privacy, trust, admission control issues involved in remote servers
(not a fatal flaw

)