12/3 Reviews - Cinder

[Rodrigo]

Please post your reviews here.

[Dan Rosenberg]

Paper Title
Apprehending Joule Thieves with Cinder

Authors
Stephen M. Rumble, et al.

Date
August, 2009

Novel Idea
The authors propose Cinder, an operating system designed to efficiently manage energy resource allocation on mobile devices.

Main Result
Cinder, which is implemented on top of the HiStar operating system, introduces the abstractions of "capacitors" and "task profiles" to model requests for energy in a hierarchy and track actual energy usage.

Impact
Cinder may provide insights on how to integrate power management as a resource primitive into the operating system, and its hierarchical scheme may be well suited for the dynamic application loads of modern mobile devices.

Evidence
N/A

Prior Work
This work most notably seeks to expand on prior results such as ECOSystem and Quanto.

Reproducibility
I'm not entirely sure as to the actual status of Cinder - it's not clear as to whether this is a design description or whether they've actually developed a working implementation.  Despite the fact that they claim to have implemented on i386, amd64, and sparc, there is no performance evaluation or other evidence to support this.

Criticism
I think the basic idea of managing energy as a resource is an important one, but I question the utility of allowing the average user to customize settings at this granularity.  I would suspect that most users are interested in their mobile device being able to complete whatever task they happen to be doing at the time, and don't consider the big picture of "if I do this now, I might not be able to do something else in two hours".

Questions/Ideas for Further Work
An obvious follow-up would be to evaluate the performance of Cinder on real mobile devices - prove that it successfully regulates power and provides easy-to-understand resource management capabilities.  A user study detailing what average users want in terms of power management would also be interesting.

[yash]

Paper Title: Apprehending Joule Thieves and Cinder.

Authors: Stephen Rumble, Ryan Stutsman and colleagues.

Novel Idea: The paper introduces Cinder, a new operating system built
on top of HiStar OS- featuring energy awareness based on hierarchical
capacitors and task profiles.

Main result: The paper describes Cinder which is designed for energy
conservation by controlling the amount of energy consumed by every
process. It achieves this extending HiStar by adding new kernel type
for energy called capacitors which is an abstraction for flexible,
dynamic and hierarchical energy management and also by maintaining
task profiles.

Impact: Saves energy, increases battery life by proper coordinating
the amount of energy to be used by programs.

Prior work: The are many related works for energy conservation such as
Powerscope, ECOSystem. Quanto, etc.

Reproducibility: The paper does not provide detailed implementation
information.

Question: How does an application react on changing the energy
(joules) allocation? Does the application developer needs to modify
his application? or simply the application will run slow?

Comments: No evalution/comparison between systems running on Cinder
and normal OS is shown.

[Spiros E.]

The paper presents Cinder, a proposed operating system architecture of
mobile devices. The main contribution of the paper a system of
allocating energy resources to processes through the composition of
objects called capacitors. These capacitors can be arranged in tree
structures and have several properties that determine the amount of
energy that it can supply to processes that are attached them.

This system seems like an embellished time-slice distribution system
that takes energy consumption into consideration. With the exception
of the hierarchical capacitors, it seems like precisely that. Frankly,
the paper hardly makes an argument supporting the need for such a
complicated system. The closest it gets it "applications are
complicated and therefore so should their energy consumption
policies." The paper isn't clear on whether the capacitor hierarchy
can be modified at runtime.

One alternative approach to solving the problem of allocating battery
resources to applications on mobile devices is to not allow
applications to run in the background. Only when an application has
the user's focus is it allowed to run and hence consume energy
resources. Though this seems overly simplistic and restrictive, this
is the approach Apple took with the iPhone, and we all know how that
turned out.

[Steve Gomez]

Author: S. M. Rumble, R. Stutsman, et al.
Paper Title: "Apprehending Joule Thieves with Cinder"
Date: In MobiHeld '09

This paper presents Cinder, an operating system intended for mobile
devices that gives users control over energy consumption policies at
the application level and software stack. Cinder introduces
abstractions for capacitors and task profiles that are used to account
energy cost. Combined with the kernel object type system of HiStar OS
(which Cinder builds off), Cinder allows for fine-grained resource
accounting and revocation of both energy and computing resources.

Prior work includes the HiStar OS, which uses hierarchical containers
to handle storage and resource accounting. The authors note that
"HiStar has no notion of superuser, which complicates resource
revocation, and makes it critical that are resources are carefully
accounted for. For this reason, it uses hierarchical containers to
account for all storage..." Cinder uses this same mechanism for
energy accounting. Other work includes the incorporation of
"cgroups" (similar to resource containers) in the Linux kernel.

As far as creating abstractions for energy use, ECOSystem presents
"currentcy" as a contain unit, but this work differs from Cinder in
two main ways, because: 1) it does not provide hierarchical energy
accounting, so it isn't as flexible, and 2) energy is distributed
evenly rather than scheduled out based on policies. Other work in
tracking energy usage has been done in systems like ECOSystem,
PowerScope, Odyssey and Quanto.

There is no evaluation of a Cinder implementation - only a walkthrough
of its design. This would also be incredibly hard to build from the
paper alone, despite nice high-level overviews of capacitor design
(concepts of potential, expenditure, input rate, and decay) and the
container/capacitor hierarchies.

A question I have has to do with how easy it is to define capacitor
policies. In section 4.2, the authors say, "it is worth noting that
capacitors can allow (potentially secret) informations to flow between
threads ... We view these as being explicitly authorized by the users
of capacitors, and, depending on the construction of the capacitor
hierarchy, they can be mitigated." This seems like it could be a real
security problem. How obvious or easy is it to design capacitors that
mitigate this problem?

My biggest criticism with the paper is just that it feels incomplete.
At the time of publication the system actually was incomplete
(according to the 'Status' section), so maybe the authors should have
held this paper off until they had successful implementations on their
sample of mobile platforms. It is hard to judge impact without a
complete picture of the system working.

[Andrew Ferguson]

Paper Title
"Apprehending Joule Thieves with Cinder"

Authors
Rumble, Stephen M., Stutsman, Ryan, Levis, Phil, Mazières, David, and
Zeldovich, Nickolai

Date
MobiHeld 2009 (co-located with SIGCOMM)

Novel Idea
The authors propose Cinder, an operating system in which energy usage,
like CPU usage, is a first-class resource. Cinder applications are
charged for their energy usage and the system/user can develop
policies to regulate the usage. The model of energy usage is known as
the "capacitor", which has an input rate (Watts), can store potential
energy (joules), and has an exponential decay for the PE store. This
way, applications can flexibly use more than their input Wattage in a
bursty fashion, but won't be able to hoard energy (due to the decay).

Main Results
This paper does not contain any detailed results. The authors indicate
that they have started work on this project and ported it to some
basic architectures, made possible due to building on previous HiStar
OS work.

Impact
Unknown, this is recent work. However, the authors will surely
continue working on the project.

Evidence
N/A

Prior Work
Methods for tracking energy usage such as Quanto, Powerscope, and
Odyssey, as well as operating systems which perform a global
accounting of energy usage such as ECOSystem. Cinder is an extension
of the HiStar OS.

Competitive Work
Unknown.

Reproducibility
The HiStar OS is open source, so the Cinder extensions could probably
be developed independently. The current HiStar code with the Cinder
work is also available.

Question
The authors mention that the Linux kernel performs energy-consuming
actions which cannot be attributed to a specific program. What actions
are they, and how should a system like Cinder deal with those actions?

Criticism
The description of multiple threads sharing a same energy-consuming
service such as the GPS is under-developed. How does the system ensure
that no thread benefits unfairly? As a user is developing energy
policies for an application, they may not know whether the device will
have WiFi or 3g or 2g connectivity in the (near/distant) future --
those modes all have different energy requirements. Finally, the
example of an extension which parses the HTML to remove the ads is a
little weak; the code to display the ads will also consume energy, and
thus it should be possible for the browser to intelligently increase a
subcapacitor above the amount set by policy if it will lower the
overall energy consumption.

Ideas for further work
Common components should have well-known energy profiles (eg, code for
network access, sensor access, etc.). Those profiles should be
available to be referenced by the developer automatically so that
developers/users have to set as few parameters as possible. In
general, I would want to wait and see what the first release of Cinder
brings before suggesting further work...

[James Tavares]

*Cinder*

Paper Title: Apprehending Joule Thieves with Cinder

Author(s): Stephen M. Rumble, Ryan Stutsman, Philip Levis, David
Mazieres, Nickolai Zeldovich

Date: MobiHeld �09. August 17, 2009.

Novel Idea: The authors contend that users have no means today to
determine how much energy an application uses, nor any means to control
how energy is dispersed to the applications running on their system in
an equitable (or user-desirable) fashion.. The authors propose a new
operating system, Cinder, which introduces two new first-class
primitives: capacitors (a flow-based method of distributing and
rate-limiting energy, while allowing for bursts), and task profiles (a
means by which users can express energy consumption in units of time,
such as �make my mail app run for 2 days�).

Main Result(s): As a short workshop paper, the paper�s primary purpose
is to introduce and justify the author�s research, as well as provide a
few examples for it potential use. The authors describe the Cinder
operating system and its new features (capacitors, task profiles). A
prototype was still in the works as of the paper�s writing, so there was
little to say there.

Impact: The capacitor framework seems like an interesting means for
processes to request and give away what amounts to energy consumption
�credits�.

Evidence: None.

Prior/Competitive Work: Cinder is an extension to the previously
developed HiStar operating system, whose security policies are expressed
in terms of �information flows�. Recently introduced �cgroups� in Linux
go some way toward replicating this functionality, but fall short of
addressing energy consumption. ECOSystem provides a �flat� energy
consumption model which the authors argue suffers under realistic
workloads as parent processes fight for resources with the children.
Finally, Quanto tracks energy use by component or operation, but does
not permit the control of energy consumption.

Reproducibility: N/A

Question: In the /gpsd/ example given in section 4.3, how are modules
policed from stealing �too many� joules from their callers?

Criticism: It�s not clear to me how the system tracks the difference
between actual consumption and advertised/available consumption?
Comparisons are made to Quanto, which tracks actual energy usage, but I
don�t see how this system tracks actual energy use.

Future Work: Are there any applications of the capacitor model to other
resources such as CPU consumption and memory allocation which might
permit more equitable resource allocation?

[Marcelo Martins]

Paper Title "Apprehending Joule Thieves with Cinder"

Author(s) Stephen M. Rumble et al.

Date ACM Mobiheld'09, August 2009

Novel Idea

Cinder is a new operating system that employs resource containers that
account for energy tracking of applications and its subtasks. In
addition, it provides feedback to users so that they can define policies
for energy usage coupled to their favorite applications. This is
possible through two main features: hierarchical composition of energy
containers that dictate how much power a process/thread and its children
can consume and a-priori energy profiling for mobile applications, so
that it can be used to estimate how much energy would be consumed for a
user-defined application.

Impact

Cinder leverages and energy metering and profiling in order to specify
energy-expensive applications and cope with their requirements while
guaranteeing that user priorities in terms of wattage can be maintained.

Evidence

The main abstraction of Cinder have been implement atop HiStar OS
running on i386, amd64 and sparc platforms. In addition, an initial port
to mobile phones has started.

Prior Work

Cinder borrows the object container abstraction from HiStar OS to define
the capacitor kernel type.

Competitive work

Cinder is in the same category as other OS extensions for energy
accounting, such as Quanto, ECOSystem and Linux's cgroups.

Reproducibility

Cinder is still under development and most of the part describes
abstractions and ideas that have yet to be demonstrated.

Criticism


Questions/Ideas for future work

Can Quanto's energy dynamism tracking be adapted to Cinder?

[Dongbo Wang]

Paper Title: Apprehending Joule Thieves with Cinder

Authors: Stephen M. Rumble, Ryan Stutsman, Philip Levis, David Mazieres, Nickolai Zeldovich

Date: 2009

Novel Ideas: The paper argues that the energy should be treated as resources in an operating system like all other regular resources. The paper proposes OS Cinder with a new fundamental kernel type for energy: capacitor. The capacitor represents the rights to request consumption of energy. It is very interesting that the paper links threads with the capacitor objects. Threads are associated with capacitors, so once a capacitor run out of potential joules, the threads associated with it will be suspended, until energy are inputed into this capacitor.

Main Result & Impact: The paper implements Cinder, a OS on top of HiStar that is added capacitor and task profiler. The Cinder enable the application-level energy resource control, and can give users useful system feedback.

Evidence: There is little evaluation on how good the Cinder works. The paper only describes several applications of the Cinder's capacitor mechanism.

Reproducibility: I think it's hard to reproduce the work in paper.

Prior Works: HiStar OS provides minimum amount of codes that need to be trusted. Linux's 'cgroups', similar as resource containers. ECOSystem.

Question and Criticism: none.

2009/12/2 Rodrigo <rodrigo...@gmail.com>

[qiao xie]

Paper Tile: Cinder   

[Novel Idea] 

Energy-aware operating systems. Support energy monitoring and control features at OS level.

[Main Results]

Energy should be allocated, accounted for and scheduled like other system resources. Cinder uses capacitors to monitor and schedule energy consumption.

Capacitors are organized as a tree to support flexible energy allocation schemas. A thread can draw energy from multiple capacitors and the effect of consumption will propagate to the root. Energy policies are generated using data in capacitors to meet users' expectations of different applications.

 

[Impact]

Users will be aware of and schedule their energy consumption to meet their goals.

[Reproducibility]

Yes. It doesn't seem hard to implement this on mobile devices.

[Prior Work]

Cinder is based on HiStar.

[Comparative Work]

Quanto, ECOsystem

[Question]

What is the cost of adding this feature?

2009/12/2 Rodrigo <rodrigo...@gmail.com>

[Juexin Wang]

Paper Tile:

Apprehending Joule Thieves with Cinder

Date:
Aug.2009

Author:
Stephen M. Rumble, Ryan Stutsman, Philip Levis, David Mazières, Nickolai Zeldovich

Novel Idea:
-Using "capacitors" for threads to manage the energy consuming.

Main Results:
-Designed the concept and mechanism of Cinder based on HiStar, which can determine the energy cost of applications and give user more access to control.

 

Impact:
- For mobile devices which is sensitive of energy, this approach, if it works, can foreseen the energy cost before running a application.

 

Evidence
-Threads are attached under capacitors, capacitors are organized into hierarchies structure. Capacitors have a designated input rate (watts) and potential energy (joules).
- Task profiles are statistics of application energy consumption. It tells the users how much energy will be charged by an application after running a given period.

.

Reproducibility
The concept is almost clearly described, but we still need the implementation details and power manage skills to make it out.

Comparative Work
ECOSystem, and potentially cgroups

Question
What principle is there in forming the capacitors into a hierarchies structure? And how to decide how much rate/energy should be allocated to one capacitor?

Do all the apps need to be rebuilt for this OS?

 

Criticism

- Lack of evaluation and performance result.
- The system doesn't analysis the code or behaviors(compute, I/O request, process communicate, visit internet... ) of a app before its running, neither can obverse the statues(idol, running, waiting, etc) of apps when generating statistical profiles, so I don't think it can predict or help decide how much energy a third-party App will consume.  

Ideas for further work
.Prove it really helps.

On Wed, Dec 2, 2009 at 6:30 PM, Rodrigo <rodrigo...@gmail.com> wrote:

Please post your reviews here.

--
J.W
Happy to receive ur message

[小柯]

Paper Title:    Apprehending Joule Thieves with Cinder

Authors:        Stephen M. Rumble
                    Ryan Stutsman
                    Philip Levis
                    David Mazieres
                    Nickolai Zeldovich

Date:           2009

Novel Idea:
    Lacking information provided by the software to measure energy consumed by third-party application is a difficult mission. Authors of this paper presented Cinder, a OS extension built upon HiStar. Cinder defines new of energy management component - capacitors which are coupled with threads to measure, record and control the energy usage. They also introduced task profile to generate policies that could meet user requirements.

Main Result:
    Cinder is create and installed on HTC Dream platform to prove its' ability.

Impact:
    Many researches are concerned detect, measurement and control of energy on embedded or mobile device without providing any info about the softwares running on it.

Evidence:
    Some simple introduction of capacitors' property, working principles, as well as task profiles.

Prior Work:
    ECOSystem, Quanto

Competitive work:


Reproducibility:
    Not pretty sure. Some more details are needed.

Question:
    The capacitors seem to limit the execution time of the thread. If one is running out of potential energy, then it blocked.
    Wouldn't that cause the original job scheduler to work unexpectedly?

Criticism:


Ideas for further work:

2009/12/2 Rodrigo <rodrigo...@gmail.com>

[Kevin Tierney]

Paper Title: Apprehending Joule Thieves with Cinder

Author(s): Rumble et. al.
Date: MobiHeld 2009

Novel Idea
Cinder is an OS that introduces the idea of closely tracking
application energy usage (through task profiles) and providing energy
to applications through virtual capacitors that are allotted energy by
the OS and lose their energy over time. Capacitors can be structured
in a tree hierarchy so that specific threads can receive portions of
the total energy a program is using. Energy can also be "donated" to
other threads, even those in different programs.

Main Result(s)
Cinder would require programmers and users to begin thinking about
energy usage more seriously.

Impact
While taking energy into account is important, I'm not sure a system
this complex will make it into production.

Evidence
None

Prior Work
This works expands on several systems that track power such as
Powerscope, and on systems that infer energy usage like Quanto.

Question
What kind of energy savings can we really expect from such a device?

Criticism
First we don't see any experimental or theoretical proof that this
device will even save any energy at all. Intuitively it's an
interesting idea, but a user study is required to see what would
happen.

I suspect many users will do the following:
1. They want maximum battery life, so they tell Cinder they want the
maximum battery life possible
2. Cinder tells them they can't watch movies, play games, or browse
the web if they want maximum battery life.
3. The user turns off energy saving features because they are annoying him

In addition, it requires programmers to do a lot of extra work to
handle passing energy around between threads. How much energy is
expended just counting who has what energy and ensuring a fair
allocation?

I also take issue with the example they use in section 4.1 about an ad
blocking extension perhaps taking up too many resources and being
stopped- How could an ad blocking extension use more resources than
the ads themselves? Ads on the web these days generally use flash or
annoying animations to get the user's attention. If anything a low
power state would automatically block ads, perhaps even most images on
a page (to reduce network usage).

Ideas for further work
Perhaps a system could be built that does more automatically and
doesn't require programmer and user interaction to function correctly.

On Wed, Dec 2, 2009 at 6:30 PM, Rodrigo <rodrigo...@gmail.com> wrote:

[Xiyang Liu]

Paper Title
Apprehending Joule Thieves with Cinder

Author(s)

Stephen M. Rumble, Ryan Stutsman, Philip Levis, David Mazières,
Nickolai Zeldovich

Date
MobiHeld’09

Novel Idea
The paper presented the design of Cinder, an energy-aware operating
system. It is built atop HiStar system. Cinder adds capacitors as a
new first-class kernel object and maintains task profiles for fine-
grained energy control.

Main Result(s)
The authors proposed a hierarchical capacitor abstraction and its
energy model. They have implemented part of the system but no details
or evaluations are provided.

Impact
Since mobile devices are becoming complex and multiprogrammed, it is
meaningful and important to have fine-grained user-specific energy
control over applications and tasks. However, we can’t predicate
Cinder’s practicality until it is implemented and evaluated on multi-
platforms.

Evidence
No empirical evidence was provided by the paper. The authors only
demonstrated their energy model and energy type hierarchy.

Prior Work
Cinder is based on HiStar system, adding a new energy type to its
original senven first-class kernel objects.

Competitive work
Cinder, ECOSystem and Quanto are all energy-aware systems. ECOSystem
uses a flat form of resource containers whereas Cinder employs a
hierarchical energy model. In Cinder’s energy model, energy of thread
or capacitor is billed from the potential energy pool of its parent
capacitor. However, Quanto tracks the the real energy consumption for
each activity and component. Quanto also tracks energy use across
multiple nodes in a network.

Reproducibility
No. The system is not actually implemented and evaluated.

Question
I’m confused with Figure 1C. How does the energy allocation happen if
thread A is blocked in billing phase?

Criticism
The paper only introduced the high level design of Cinder, lacking of
implementation details. It is hard to appraise a system design without
detailed specification.

On Dec 2, 6:30 pm, Rodrigo <rodrigo.fons...@gmail.com> wrote: