Reviews: MAUI

[Rodrigo Fonseca]

Hi,

Please post your reviews to MAUI here.

Thanks,
Rodrigo

[Shah]

Title:

MAUI: Making Smartphones Last Longer with Code Offload

Authors:

[1] Eduardo Cuervo
[2] Aruna Balasubramanian
[3] Dae-ki Cho
[4] Alec Wolman
[5] Stefan Saroiu
[6] Ranveer Chandra
[7] Paramvir Bahl

Source and Date:

MobiSys '10 Proceedings of the 8th International Conference on Mobile
systems, Applications, and Services.

Novel Idea:

The authors present a novel system that reduces the power consumption
required in energy-hungry devices.

Main Result:

The scientists present MAUI a system that maximizes energy savings in
mobile devices. It decides, at runtime, which methods should be
remotely executed given the mobile device’s current connectivity
constraints.

Impact:

Since this paper was only launched earlier this year, it has yet to
make an impact. As of this writing, there are only a few other papers
that reference this one.

Evidence:

The authors evaluate MAUI’s performance on four applications:

[1] A face recognition application

[2] A video game

[3] A chess game

[4] A translator

The first three are built-in Windows applications. The last one was
built from scratch. Then, they perform three microbenchmarks that
check:

[1] MAUI’s primary goal to reduce energy

[2] MAUI’s secondary goal to improve the performance of mobile
applications

[3] MAU’s third goal to run resource-intensive application

Prior Work:

The authors list several works in this area. These include Chroma,
CloneCloud, OLIE and Wishbone.

Competitive Work:

The authors don’t specifically list competitive work.

Reproducibility

The authors don’t necessarily provide too much detail to make the
experiments completely reproducible. However, they do conduct a series
of experiments.

Question:

The authors present a cool idea. Will this catch on?

Criticism:

More transparency on the experiments front would’ve made things
clearer. Also, they state that MAUI’s energy-savings are ‘impressive’
but perhaps making such a qualitative statement is not always
acceptable. Maybe a more neutral tone would be.

Ideas for Further Work:

None

[Sandy Ryza]

Title:
MAUI: Making Smartphones Last Longer with Code Offload

Authors:

Eduardo Cuervo, Aruna Balasubramanian, Dae-ki Cho, Alec Wolman, Stefan
Saroiu, Ranveer Chandra, Paramvir Bahl

Date:
MobiSys '10

Novel Idea:
The authors present MAUI, a system for offloading of mobile code
execution onto remote servers with method-granularity. At runtime,
the system decides whether or not to offload method based on a remote
solver that considers the current environment to optimize with respect
to power consumption. The system relies on the ability of managed
code to be run on different platforms.

Main Result(s):
They find that MAUI improves both energy consumption and performance
(to varying degrees depending on the application - performance by a
factor of eight for a particular face recognition application) for a
few applications that they tested it on. It also enables applications
that exceed memory limits to run on phones. They find that their
system provides larger gains in environments with low server-to-phone
communication latencies and does not provide any gains when running
over 3G.

Evidence:
They authors tested their WORD on three pre-built applications. They
ran each application in 6 different scenarios: standalone on the
smartphone, four different simulated Wi-Fi latencies, and on 3G. They
monitored performance and energy consumption. They also built an
application that uses more memory than their smartphone can handle and
demonstrate that they are able to run it with remote offloading. They
also performed a series of microbenchmarks to evaluate the performance
overhead of their optimizer, the gain provided by passing only deltas
of program state, and how their solver adapts to changing conditions.

Prior Work:
Spectra and Chroma leave it up to the programmer to partition the
program between phone and remote server, and allow different
partitionings based on different qualities of service. Coign
automates partitioning of DCOM applications into client and server
components with coarser grain size. Hydra does finer grained
offloading to specialized processors such as GPUs. OLIE dynamically
partitions Java applications at runtime in a similar way to MAUI, but
focuses on memory constraints instead of energy consumption.

Competitive Work:
CloneCloud also automatically and dynamically partitions mobile
applications using a similar architecture, but supports
multithreading, has a VM-based model, and does not target energy
consumption like MAUI.

Reproducibility:
Neither the code for the system or the applications they tested it on
are available, so both the system and results would likely be
difficult to reproduce.

Criticism:
On page 6 they describe their method for estimating power used based
on measurements taken from a single phone- do these measurements not
vary from phone to phone?

Question:
The authors state that MAUI has only limited support for multi-
threaded applications (they only offload methods from a single thread
at a time). What challenges would we expect to encounter in spreading
offloading to multiple threads?

[Matt Mallozzi]

Matt Mallozzi

11/23/10

Title:

MAUI: Making Smartphones Last Longer with Code Offload

Authors:

Cuervo, Balasubramanian, Cho, Wolman, Saroiu, Chandra, Bahl

Date:

2010

Novel Idea:

Offloading code executing on a mobile phone to the cloud in a fine-grained,

energy-optimized way that does not require significant programmer

modification.

Main Results:

A working system based on .NET that can offload managed code running on

Windows Mobile to servers, thereby saving energy for the mobile phone. This

uses a combination of code portability, serialization, reflection, type

safety, and integer linear programming to achieve the desired results.

Impact:

This could have a huge impact on mobile applications. One, this opens up a

whole new class of applications that would have been prohibitive or even

impossible to run just on a smartphone. Two, this allows developers who

are unfamiliar with the energy-aware practices of programming mobile phone

applications to worry only about marking methods Remoteable according to

the given set of rules, and letting the runtime optimization and offload

system take care of making the code battery-efficient.

Evidence:

Several smaller tests to check and verify assumptions (energy usage of CPU,

3G, WiFi). A variety of sample applications with different performance

needs, along with benchmarks on how each application was improved with

regards to performance and battery usage. A series of microbenchmarks to

evaluate the overhead and effectiveness of the solver, the effectiveness of

program state transfer deltas, and the ability of the solver to adapt to

changes in the conditions under which the program is running.

Prior Work:

Many previous systems upon which MAUI builds either require too much manual

programmer restructuring, or are too coarse-grained to have much effect.

Competitive Work:

OLIE is a similar system that allows for fine-grained runtime partitioning

of mobile Java applications with minimal programmer restructuring, but

which attempts to overcome smartphone memory constraints rather than battery

constraints. The authors do not make it very clear how the two systems

differ except for in the optimization problem.

Reproducibility:

Some of the details are a bit vague, but overall the system was described

fairly well.

Question:

How are methods from a multi-threaded program (even if they are just from

a single thread) offloaded to the server? It seems like there would be extra

work that is not mentioned - when the state (referenced variables) for a

method to be called remotely is serialized, any threads that interact with

any variables in that state must be paused until the remote invocation

returns to the mobile device.

Criticism:

They only tested using one phone model.

Ideas For Further Work:

Do this for Java, or combine these results with OLIE. Could the optimization

problems of MAUI and OLIE be combined by providing comparative weights to

the objective values of energy consumption and memory usage, or could one

of these objectives be reformulated as a constraint in the optimization

problem of the other?

[Zikai]

Paper Title: MAUI: Making Smartphones Last Longer with Code Offload

Author(s): Eduardo Cuervo, Aruna Balasubramanian, Dae-ki Cho, Alec
Wolman, Stefan Saroiu, Ranveer Chandra, and Paramvir Bahl

Date/Conference: MobiSys 2010

Novel Idea: Support fine-grained offload of mobile code which
minimizes energy consumption and burden on programmers by combing
method annotations, static device profiling, dynamic program/network
profiling and dynamic linear programming problem solver.

Main Results: (1) Design and implement MAUI, a system that enables
fine-grained energy-aware offload of mobile code to computing
infrastructure while reducing burdens on programmers.
(2) Evaluate MAUI with four mobile applications including resource-
intensive one, latency-sensitive one and one exceeds memory limitation
of the smart phone. Energy consumption, latency and a series of micro-
benchmarks are used as performance metrics.

Impact: MAUI provides currently the best way of offloading a mobile
program while balancing energy saving and programmer burden
minimization.

Evidence: (1) In part 5.3, program profiling overhead with different
strategies are tested.
(2) In part7, MAUI is evaluated with four diverse mobile applications
(resource-intensive , latency-sensitive, exceeding memory limitation
of the smart phone). Energy consumption and latency are used as macro-
benchmark metrics. A series of micro-benchmarks are also tested like
overhead for MAUI’s solver.

Prior Work: Microsoft .NET Common Language Runtime [36], .NET
Reflection API [22,36], JouleMeter[19]

Competitive Work: In part8, authors discuss competitive work in
program partitioning and process/VM migration.

Reproducibility: The paper is clear on all the necessary parts needed
to construct MAUI. Though great efforts are needed, it is still
possible to implement MAUI based on the paper and reproduce the
experiments.

Question: (1) One of the main advantages of MAUI is to put minimal
burden on programmers. However, authors also admit that additional
program modifications can bring performance benefits. Are energy
saving and performance without any additional modification good enough
for most mobile programs? Or is it the case we have to modify programs
in most circumstances?
(2) Is the linear model that relates smart phone CPU utilization and
energy consumption good enough for smart phones with all kind of
architecture and power supply design? Is it realistic to use the power
meter to test each smart phone before we use MAUI? How can we deal
with the common situation that a battery’s capacity goes down when it
gets old? Do we have to periodically re-profile the device?
(3) MAUI depends on Microsoft .NET Common Language Runtime to
implement code portability and this only works on smart phones running
Windows Mobile. However, a large proportion of smart phones are
running Android or Symbian. Do we have similar supporting framework
for them?

Criticism: MAUI has high dependency on fast Wi-Fi network and it
performs bad in common 3G network. However, for most of the time,
smart phones go without Wi-Fi. Therefore, applicability of MAUI is
doubtful.

On Nov 22, 7:59 pm, Rodrigo Fonseca <rodrigo.fons...@gmail.com> wrote:

[James Chin]

Paper Title: “MAUI: Making Smartphones Last Longer with Code Offload”

Authors(s): Eduardo Cuervoy, Aruna Balasubramanianz, Dae-ki Cho, Alec
Wolmanx, Stefan Saroiux, Ranveer Chandrax, and Paramvir Bahlx

Date: 2010 (MobiSys ‘10)

Novel Idea: This paper presents MAUI, a system that enables fine-
grained energy-aware offload of mobile code to the infrastructure.
Previous approaches to these problems either relied heavily on
programmer support to partition an application, or they were coarse-
grained requiring full process (or full VM) migration. MAUI uses the
benefits of a managed code environment to offer the best of both
worlds: it supports fine-grained code offload to maximize energy
savings with minimal burden on the programmer. MAUI decides at
runtime which methods should be remotely executed, driven by an
optimization engine that achieves the best energy savings possible
under the mobile device’s current connectivity constrains.

Main Result(s): The authors’ evaluation shows that MAUI enables: 1) a
resource-intensive face recognition application that consumes an order
of magnitude less energy, 2) a latency-sensitive arcade game
application that doubles its refresh rate, and 3) a voice-based
language translation application that bypasses the limitations of the
smartphone environment by executing unsupported components remotely.

Impact: Today’s mobile users expect their smartphones to run
sophisticated applications, they have almost ubiquitous access to 3G
connectivity, and their computing applications are moving to the
cloud. MAUI’s goal is to mitigate the energy problem for mobile
handhelds, the mobile industry’s foremost challenge. By offering
dynamic fine-grained code offload with minimal burden on the
programmer, MAUI offers significant energy and performance benefits to
mobile applications.

Evidence: The authors evaluated MAUI’s ability to improve the energy
consumption and performance of smartphone applications using a
combination of macrobenchmarks and microbenchmarks. Specifically,
they looked at three macrobenchmarks that characterized MAUI’s ability
to reduce energy, improve performance, and bypass the resource
limitations of smartphones. They also looked at four microbenchmarks
that characterized the behavior of both the MAUI solver and the MAUI
proxy.

Prior Work: Most of this paper’s previous work used remote execution
to increase the performance and improve the availability of of
resources, such as faster CPU’s and more RAM, for mobile applications.
Some previous efforts sought to balance the thirst for performance
with energy conservation because these goals can sometimes be
contradictory. In contrast, MAUI’s primary goal is using remote
execution to save energy. With MAUI, code is offloaded to a remote
server only if MAUI predicts that remote execution ends up saving
energy.

Competitive Work: Recent work includes the Zap project, which enables
process migration using OS support for checkpoint and restart. The
CloneCloud system and Cloudlets project suggest applying the technique
of moving an entire OS and all its running applications to mobile
device environments. These approaches drastically reduce the burden
on the programmer. However, MAUI’s focus on energy savings led the
authors to choose a design that is more aggressive and exploits more
opportunities to offload code. This includes the ability to offload
portions of a single application; the authors did not want to restrict
MAUI’s code migration to the granularity of a whole process or an
entire OS.

Reproducibility: The findings appear to be reproducible if one follows
the testing procedures outlined in this paper and has access to the
code for MAUI.

Question: Are there applications that wouldn’t get a performance boost
with MAUI?

Criticism: The paper only focuses on four specific applications in its
evaluation.

Ideas for further work: Test and integrate MAUI into the application
frameworks for other common mobile operating systems, including
Symbian OS, Android, iOS, and RIM Blackberry OS.

On Nov 22, 7:59 pm, Rodrigo Fonseca <rodrigo.fons...@gmail.com> wrote:

[Abhiram Natarajan]

Paper Title: MAUI: Making Smartphones Last Longer with Code Offload

Author(s): Eduardo Cuervo, Aruna Balasubramanian, Dae-ki Cho, Alec

Wolman, Stefan Saroiu, Ranveer Chandra, Paramvir Bahl

Date: 2010, MobiSys

Novel Idea: The key idea in MAUI is to use fine-grained code offload
to a nearby infrastructure or the cloud to reduce processing on the
mobile phone. Specifically, MAUI uses the concepts of 'code
portability', 'programming reflection', 'type safety' and
'serialisation' to effect.

Main Result(s): An architecture that maximises the potential for
energy savings through fine-grained code offload while minimising the
changes required to applications. The authors show using mobile phone
experiments that MAUI reduces power consumption by over 50% for video
game and face recognition
applications.

Impact: MAUI makes decisions at run-time as to which methods should be
remotely executed. It is driven by an optimisation engine that
achieves the best energy savings possible under a mobile device's
connectivity constraints.

Evidence: MAUI is shown to
(1) Improve the energy consumption of resource-intensive
applications, such as face recognition, by almost one order of
magnitude
(2) Allow latency-sensitive applications, such as games, to more than
double their screen refresh rates

Prior Work: There is tons of relevant work in the following areas:
(1) Program Partitioning - Spectra, Chroma, Prism, Odyssey, Protium,
Emerald, Network Objects, Obliq, Rover, Agent Tel, Automatic Program
Partitioning Systems, Coign, Work by Kremer et al., Hydra, Wishbone,
Data Staging, Fluid Replications, OLIE
(2) Process and VM Migrations - Sprite, Amoeba, Zap, CloneCloud,
Cloudlets

Competitive Work: The authors extensively evaluate MAUI's ability to

improve the energy consumption and performance of smartphone

applications, using a combination of macro-benchmarks and micro-
benchmarks.

Reproducibility: The paper is a little low on details, so would not be
too easy.

Criticism: I get the feeling that in instances where methods contain a
lot of user-interaction, MAUI would be impractical. Also, programmers
need to mark some methods manually.

On Nov 22, 7:59 pm, Rodrigo Fonseca <rodrigo.fons...@gmail.com> wrote:

[Hammurabi Mendes]

Paper Title

MAUI: Making Smartphones Last Longer with Code Offload

Authors

Eduardo Cuervo, Aruna Balasubramanian, Dae-ki Cho, Alec Wolman, Stefan
Saroiu, Ranveer Chandra, Paramvir Bahl

Date

MobySys'10 - International Conference on Mobile Systems, Applications
and Services, June 2010

Novel Idea

Offloading programmer-marked methods in smartphone applications to
servers according to a global optimization function that maximizes
energy savings.

Main Results

The paper presents a system called MAUI, which moves parts of
smartphone applications to servers, allowing energy savings. The
decision on whether to execute methods locally or remotely is made by
an optimization system running on a server, which depends on
measurements done locally. When a code offload is decided, the local
state required to start the method in the server is also passed.

Impact

The system not only allows smartphone applications to save power, also
allows them to execute applications that use more resources than those
available locally.

Evidence

The structure of the argumentation is as follows. The discussion
starts by characterizing the problem, also analyzing how 3G and high
RTTs would impact code offload. Then, the paper describes the
architecture (including details on how to run the code, and how to
identify parts that might migrate). They describe how the local
measurements are made (including profiling overhead), how the
optimization problem is modeled and finally evaluate the system.

The evaluation compares energy usage at WiFi/3G, and with different
RTTs, but also analyze performance and server load (CPU/memory). They
also analyze how much difference using incremental affects on local
state size on code offload. The results are interesting, except from
some particular cases.

Comments regarding the effectiveness of the argumentation/evaluation
are on the Questions+Criticism section, as usual.

Prior Work

They cite Odyssey, Spectra, Chroma, and mention that MAUI automates
"many" steps for partitioning applications.

They then mention Emerald, Network Objects, Obliq, Rover and Agent
Tcl, and mention that these (1) don't "hide distribution from the
programmer"; (2) don't "focus on automating migration to optimize for
energy consumption".

They also cite other systems (Cign, Hydra, Wishbone), somehow implying
that their ideas need adaptation to the current scenario.

Competitive Work

They mention an alternative approach, of using a distributed
application. Also, incorporating OS support for process migration is
discussed. They also cite the OLIE system, which they say that focuses
on "overcoming the memory resource constraints", instead of saving
energy.

Reproducibility

I believe the experiments are reproducible, but apparently with
different applications (I don't think the applications in the paper
are specifically mentioned and/or are freely available). However, I
believe it is possible to find applications with similar
characteristics to the ones considered in the paper (specially because
nowadays there has been an enormous variety of smartphone
applications). Therefore, I would say that the experiments are still
reproducible.

Questions + Criticism

[Criticism] This is a very good paper. It has merits on its
presentation, readability, and quality of argumentation.

I missed more discussion on how much *energy* is spent under different
strategies on calculating deltas. They somehow imply the CPU usage
when they analyze how many FPS the game application sustains (sec
5.2.1), and network usage (sec 7.2.3), and these both imply energy
impact. [Question] But, how much exactly the delta calculation spends
on energy? Up to what point these strategies are "viable" as memory
and CPU resources on smartphones become more available, but battery
(apparently) doesn't?

Anyway, I think this is a remarkably good paper.

Ideas for Further Work

There could be a cloud-based service where application developers
preload application code into it such that:

(1) it can provide a way for the developers to specify policies that
"hint" the MAUI server on how to make decisions about offloading;

(2) keep a history of code executions across different clients that
use the service to increase this hint accuracy (for example: "after
this execution, if the client profiler asks you for executing method
X, accept it -- it has been good for 93% of the other users, and the
delta is fairly small"). MAUI uses history on the program profiling,
but why not use it on the server side?

On Mon, Nov 22, 2010 at 7:59 PM, Rodrigo Fonseca
<rodrigo...@gmail.com> wrote:

[Duy Nguyen]

Paper Title 

MAUI: Making Smartphones Last Longer with Code Offload

Authors 

Eduardo Cuervo, Aruna Balasubramanian,...

Date 

MobilSys 2010

Novel Idea

A framework for saving energy of Windows Mobile based smartphones by offloading

the mobile code to dedicated infrastructure servers.

Main Results 

The authors described the architecure and evaluation to show that the ideas are

doable. The framework has 3 main components: program partitioning, profiler and

solver. The developers indicate which procedures of the application can be run

remotely. The profiler module collects information about these functions and related

data. The solver uses information produced by profiler to decide which functions will

be offloaded. These decisions are generated on-the-fly when the solver is asked by

the partitioning module.

Impact 

Not know yet.

Evidence 

The evaluation is described at length. It shows some good number: MAUI saves 27%

energy for video game and 45% for chess program, MAUI allows a 32MB-RAM smartphone 

running a resource-intensive application which consumes about 110MB of RAM.

Prior Work 

MAUI is built upon many past works in program partitioning and process migration

Competitive Work 

Unknown. 

Reproducibility 

No. Need more details in order to reproduce this work

Question/Criticism

N/A

On Mon, Nov 22, 2010 at 7:59 PM, Rodrigo Fonseca <rodrigo...@gmail.com> wrote:

[Siddhartha Jain]

Siddhartha Jain

Title: MAUI

Novel Idea:
A method to enable remote execution of tasks oriented towards the mobile space. Combined ideas from both fine-grained programmer specified partition of the program and coarse-grained process migration frameworks.

Main Results:
The framework is presented and evidence of its effectiveness is given

Evidence:
It compares well against the naive method of executing everything in the mobile phone.

Prior Work:
Fine-grained specification for program partitioning and coarse-grained process and VM migration

Reproducibility:
Does not seem to be available for download so hard to reproduce. The program method annotations would be especially annoying if one wanted to reproduce the results.

Criticism:
Comparison with fine-grained methods and process and VM migration methods lacking.

Question:
How is cache performance affected by this? If several functions are marked as ok to run remotely but the linear program keeps choosing different ones, then the cache hit rate might be affected badly leading to bad performance (say if different variables are being used by different methods).  Making this cache aware would be interesting.

Ideas for future work:
Making the language for specifying remote execution richer. If for some method, the failure cost is high in some specific scenarios, then we would want that to execute locally even though in most other circumstances, it can be remotely executed.

On Mon, Nov 22, 2010 at 7:59 PM, Rodrigo Fonseca <rodrigo...@gmail.com> wrote:

[Jake Eakle]

Paper Title	MAUI: Making Smartphones Last Longer with Code Offload
Author(s)

Eduardo Cuervo, Aruna Balasubramanian, Dae-ki Cho,  Alec Wolman, Stefan Saroiu, Ranveer Chandra, Paramvir Bahl

Date	2010
Novel Idea	Use remote execution to increase the performance capabilities and battery life of mobile devices. Moreover, use dynamic profiling with input from the phone's networking services to determine which functions to run remotely.
Main Result(s)	They describe MAUI, a framework that implements the strategy described above. It leverages the .NET CLR to enable process migration across the network despite the differing CPU architectures used on mobile devices and cloud servers. It has a number of components: To know which parts of an application are available for migration, MAUI requires that the programmer annotate all remoteable methods. They chose this method over having local annotations (which might result in better performance, since there are likely to be fewer) to prevent program semantics changing if an annotation is forgotten. MAUI uses the custom attribute feature of the .NET CLR to identify these marked remoteable methods at compile time. For each such remoteable method, MAUI generates a wrapper that will serialize all the state it needs, send it to the remote version of the application, and then update the local state with the new state returned by the remote call. They currently serialize almost everything the method could possibly want, which is pretty bad. If a remote method calls an unremoteable method, the temporary state is sent back to the device, and the wrapper handles calling the local method and then packing the new state back off the the server so the remote function can be completed.  When contact to the server is lost, MAUI ensures that it is possible to execute the remoteable method locally instead (it also offers the possibility of looking for another MAUI server). It can make this guarantee because state is only transferred at the start and end of methods (they claim. See 'questions'.) and they tell programmers not to mark as remoteable any methods with 'real-world' side effects (ie, effects outside the address space of the program itself, such as methods that update other servers, or that manipulate physical output devices). The next component is the Profiler, which instruments each method to determine how much battery power it will take to execute, which they base off the number of CPU cycles it requires. The Profiler also observes the networking environment, and passes its findings into the Solver. This aspect led them to some very interesting results, such as the fact that Power Saving Mode actually uses more power at low network latencies due to TCP slow start.  The Solver uses optimization techniques to decide from the output of the Profiler whether or not to offload each method.
Impact	Hopefully a lot, soon! This was a very impressive paper, and despite seeming like a kind of unwieldy idea, it looks like it really can be made to work.
Evidence	They have a very good Evidence section, in which they evaluate MAUI on a variety of existing applications, and show both concrete benefits, and the point at at which MAUI makes things worse, both for energy consumption and performance.
Prior Work	A bunch of VM migration stuff.
Reproducibility	No code given, but no secret sauce withheld either - it would take about as much work as they already did, but the information to reproduce it is mostly here.
Question	I don't really understand how failure tolerance works -- if a remote method has to call a local method, state must be transferred during the execution of a method, which seems to violate their invariant.
Criticism	They have a whole paragraph dedicated to why 3G has a terrible amount of battery consumption, and isn't even worth it -- and then they conclude that paragraph by saying MAUI uses both, with no explanation. ??? [Having now read the evaluation section, which seems to show that 3G almost always hurts performance, but MAUI figures that out and doesn't use it, this makes a little more sense, but still -- is it even worth considering? They don't show a case where offloading over 3G is a good idea.]
Ideas for further work	Further research into detecting at runtime what objects need to be serialized seems like both a necessity to make MAUI really perform well in the field, and also a meaty research topic with many broader applications.

--
A warb degombs the brangy. Your gitch zanks and leils the warb.

[Basil Crow]

Title: MAUI: Making Smartphones Last Longer with Code Offload

Authors: Eduardo Cuervo, Aruna Balasubramanian, Dae-ki Cho, Alec
Wolman, Stefan Saroiu, Ranveer Chandra, and Paramvir Bahl

Date: MobiSys 2010

Novel idea: By offloading mobile code to non-local infrastructure, we
can reduce energy utilization and improve performance on mobile
devices. In some cases, we can even run resource-intensive
applications on a mobile device which would be impossible to run
otherwise.

Main results: The authors' implementation uses the .NET CLR and
depends on programmers marking certain methods as "remoteable."
Proxies on both the client and server side handle control and data
transfer for offloaded methods. Finally device, program, and network
profiling data is collected and used by the MAUI solver in order to
determine which methods should execute locally and which should
execute remotely.

Evidence: The authors evaluate MAUI on four applications and show its
energy savings and performance improvements (which were in several
cases substantial). They also show that MAUI can be used to run a
resource-intensive application on a mobile device which would be
impossible to run otherwise. The authors also provide a serious of
microbenchmarks to show that MAUI's solver runs with low overhead and
that incremental deltas are effective at reducing MAUI's data transfer
overhead.

Prior work: The authors mention previous work in the area of program
partitioning (Spectra and Chroma).

Competitive work: Unlike CloneCloud, MAUI is not designed to handle
multi-threaded applications.

Reproducibility: It does not appear that source code is available.

[Rodrigo Fonseca]

On behalf of Tom:

MAUI: Making Smartphones Last Longer with Code Offload

Eduardo Cuervo, Aruna Balasubramanian, Dae-ki Cho, Alec Wolman, Stefan Saroiu, Ranveer Chanra, Paramvir Bahl

MobiSys 2010

Novel Idea:

MAUI leverages managed code languages to offer fine grained computation offloading.  Their primary goal is to reduce power consumption on mobile devices.  It uses reflection rather than static analysis to determine where a method should run. It decides at runtime to remotely execute a method based on a set of constraints given the history of past method calls.

Main Result:

They demonstrate that MAUI can successfully reduce power consumption on mobile devices in some applications. 

Evidence:

First they attempt to measure the overhead of running MAUI. They test the effects of various serialization optimization heuristics and the effect of using a phone's power saving mode (PSM) while using MAUI.  To evaluate MAUI, they define questions about MAUI's performance they want to answer, and then each subsection describes how they went about answering the question and the results. I thought it was a nice format. They use four test applications, an interactive game, chess, face recognition and a translation tool designed from scratch to demonstrate how MAUI can be used to exceed the memory limitations of mobile devices

Impact:

Like CloneCloud, it seems like a great idea.  However, it will only catch on if there is widespread deployment, which would be a large investment for service providers.

Reproducibility:

Like most Microsoft papers, it is only good as a high level overview.  I don't think there is source code available. Their tests were well documented.

Prior/Competitive Work:

They mention lots of related work. Spectra and Chroma let the developer specify program partitions. Protium allows you to manually partition your app into a remote logic execution and local viewers. [28] and [23] use static analysis to automatically partition applications.  They mention Sprite, Amoeba and Zap as systems that do OS process migration. Finally they mention CloneCloud and Cloudlets which do VM migration with a focus on Mobile devices.  

Questions:

Does the client side MAUI profile consider the effect of itself on the system's energy consumption? 

Criticism:

Neither MAUI nor CloneCloud evaluate the negative effects of an overloaded server.  Slow response times or outright server failure would have a huge impact on the effectiveness of these types of systems.

Future Work:

There are many improvements to be made to MAUI. Support for remote execution of more than one thread seems like a big one.  There are also many security issues that would have to be addressed before a product is released.

On Mon, Nov 22, 2010 at 7:59 PM, Rodrigo Fonseca <rodrigo...@gmail.com> wrote:

[Dimitar]

Authors: Eduardo Cuervo, Aruna Balasubramanian, Dae-ki Cho, Alec
Wolman, Stefan Saroiu, Ranveer
Chandra, Paramvir Bahl

Date: June/2010

The paper presents MAUI, a system that maximizes energy savings
through fine grained code offload
while requiring very little work from programmers. The only thing that
developers need to do is to
decide of the initial partition of their application, and leaves the
decisions of which method should be
offloaded at runtime to MAUI.

Results: Designing and implementing a system that maximizes energy
savings. MAUI uses code
portability to create local and remote version of an application. It
uses programming reflection and
typed safety to identify which methods should be run remotely. Lastly,
MAUI uses serialization
to determine the network shipping cost.

Impact: Code Offloading combine with easy to use partitioning method
could have significant impact
of how applications are run on the smartphones.

Evidence: The authors tested MAUI using four different applications
(three of them were pre-built
and the other one was build from scratch). The main goal of the tests
was to show that MAUI improves
energy efficiency, and it increases performance. The three
macrobenchmarks created by the authors
show that this is indeed the case. They also created four benchmarks
that characterize the behavior of
MAUI proxy and solver.

Prior Work: MAUI borrows idea from Chroma , but the key difference
between them is that Chroma
puts the burden into application developers by allowing them to
specify “tactics” of how application
can utilize the infrastructure.

Competitive Work: Zap allows process migration using checkpoints and
restart, and like MAUI
eases the burden to programmers.

Reproducibility: The design and implementation of MAUI are clearly
explained in the paper, but it
will take a great effort to reproduce their work.

Criticism: The test cases presented by the authors don't show how
applications are affected
by a server failure.

[Joost]

Title: MAUI: Making Smartphones Last Longer with Code Offload
Authors: Eduardo Cuervoy, Aruna Balasubramanianz, Dae-ki Cho, Alec
Wolmanx, Stefan Saroiux, Ranveer Chandrax, Paramvir Bahl
Date: 2010

Novel Idea: This paper establishes a system whereby battery life on
mobile devices can be saved by offloading intensive computation from
the phone and executing it remotely. The authors seek to accomplish
this in a generic fashion which minimizes the required changes to
applications to make use of these features.
Main Results: The authors successfully implemented a platform to
offload processes from a mobile device for remote execution. They do
this by cloning the application to be run onto a remote site, and
caluclating based on factors such as local bandwith, shipping cots,
and latency to determine which parts of the code to port over to the
remote site and which to run locally.
Impact: Such measures will decrease the amount of battery usage per
application on smart phones, as well as improve the usage performance
on these phones. However, with the exception of massive computations,
few applications used on a regular basis would seem to have anywhere
near the computation size to make this a worthwhile exercise.
Evidence: The authors compared energy consumption on a smartphone
without MAUI to smartphones with MAUI under different Wi-Fi/3G
configurations. On face recognition, the MAUI phones massively
outperformed the generic smartphone by an order of magnitude in energy
consumption and computation time. With regards to 400 frames of a
Video game and a 30 Move Chess game however the energy usage was
comparable with the 3G setting performing worse in both cases.
However, in the Video Game case the frame rate was between 2.5 and 5
times higher with the MAUI implementation.
Prior Work: The paper builds on a lot of previous partitioning
research including Wishbone, Spectra and Chroma. It also draws from
Migration work in Zap and CloneCloud
Reproducibility: Given the time and resources a similar system could
be built and tested, however without source code it wouldn't be exact.
Question/Criticism: How long will it be before this type of usage is
commercially viable? How hard is it to port an application over to
this type of device? How much of the automation in these systems of
porting or not would be done behind the scenes and how much would be
left up to the user?

On Nov 22, 7:59 pm, Rodrigo Fonseca <rodrigo.fons...@gmail.com> wrote: