I worked this summer on the Milly Watt Project with Carla Ellis at Duke University. We focused on working to extend the ECOSystem operating system.

Milly Watt Overview

As the field of mobile computing grows, the issue of power consumption is becoming more and more important. More and more research is being done in the area of reducing power consumption. With mobile computing (laptops and wireless sensor networks), this allows an extension in battery lifetime. In more traditional computing platforms (servers, etc.) a reduction in power consumption can reduce fan noise, heat pollution, and energy costs. And, of course, in today's eco-aware world, it is always desirable to lessen environmental impact by conserving energy. The Milly Watt Project maintains that a key step in the reduction of power consumption is the management of energy as a primary system resource. This goal envisions the cooperation of applications and system in energy management. A primary question was asked: What can be accomplished in energy management within an operating system

ECOSystem Overview

ECOSystem stands for Energy Centric Operation System. It was the answer to that question. In its original implementation, ECOSystem required no special adaptation from applications - it could (and can) run them straight out of the box. This operating system achieved two goals: reaching a desired battery lifetime and allocating available energy proportionally among running applications. To accomplish these goals, a framework called the "Unified Currentcy Model" was developed. In this model, energy is treated in terms of currentcy - the right to use of a certain amount of energy within a certain period of time. By limiting the battery discharge rate over time, ECOSystem can achieve a reasonable, specified battery lifetime. According to this discharge rate, each epoch (1 sec for example), a proportional amount of currentcy is given to each active process. The process is charged for use of the CPU, the hard drive, and the wireless network card. If it runs out of currentcy before the epoch is over, it must wait until it receives more currentcy in the next epoch.

All of this, of course, had already been accomplished when I arrived at Duke this summer. Carla and I decided that a reasonable next step for ECOSystem combined two ideas: that of enlisting the cooperation of energy-aware applications and that of making ECOSystem a more energy-efficient operating system. Our goal was to create a set of API extensions that allowed energy-aware applications to pass information to the operating system, allowing the operating system to manage hard disk accesses more efficiently. We wanted to make this interface simple, easy-to-use, and backward compatible. But, almost most importantly, we wanted to think of all energy savings in terms of our currentcy model.

Disk Management

In order to talk about saving energy on disk accesses, I have to explain a little bit about disk management. Hard disk drives have different power states. While the disk is actually being accessed, it is in the highest power state, consuming the most power possible. However, if it is not accessed for a period of time, it can slow its spinning and enter a more idle state which consumes less power. If a disk is not accessed for a long period of time, it can stop spinning and enter standby mode. In standby mode, it does not consume any power. However, the amount of energy required to transition between standby and active mode is prohibitive. In order to save energy on the disk drive, we aim for two things. It is desirable to maximize the amount of time the drive spends in standby while minimizing the number of transitions it makes from standby to active mode. Most hard disks come with their own spindown policy, however, they have no control over the timing of the disk requests. Our goal in ECOSystem was to delay read and write disk requests before they are issued to the disk drive. The idea is to clump accesses together so that they happen in a short period of time, allowing the disk to spend more time in standby.

Bidding and Priorities

How in the world can we force our disk accesses to cooperate? The first element of the puzzle is creating a high "entry price" for disk access. Once the disk spins down (enters standby), we label disk access with a price greater than the actual energy cost for the transition from standby to active. Then, when a disk request occurs (say a read is issued), it tells the operating system how much currentcy it is willing to contribute toward paying this high entry price. We termed this process "bidding." The process that wants to access the disk has to wait until enough other processes have gathered that the sum of all their bids exceeds the entry price. Using this mechanism, we delay the first disk access until there are a group of requests waiting. This allows the disk to stay in standby mode longer, saving energy. A good question remains: how do we know how much a process is willing to "bid"? This is where the energy-aware applications enter the picture. Using new system calls for read, write, and open, the application can specify a priority for a disk access. This priority determines how much of the currentcy available to the application will be committed to a bid for disk access. Obviously, the higher the priority is, the more likely it is that the entry price will be met.

Since I knew next to nothing about ECOSystem when I arrived, the first step was to catch up on the research that had already been done. So I started by reading papers about ECOSystem. I also read a paper by another group who had researched using cooperation between applications and operating system in order to manage disk I/O more efficiently. Then Carla asked me to develop an overall plan/vision for implementing a type of bidding process in ECOSystem that allowed the operating system to delay disk reads and writes. I presented this plan to some other members of the Milly Watt Project (kind of intimidating!). I still knew very little about how ECOSystem was actually implemented, though. Later I would discover just how many of my ideas were not quite right. I spent quite awhile after that learning to navigate the Linux source code. Then I worked on developing a code design for the changes I wanted to make. It took kind of awhile to get the laptop I needed to actually do the programming, and then we had to configure it properly, so I only ended up with about two weeks to work on the actual implementation. I learned how to compile the Linux kernel and work inside of it all in a rush! I implemented the new system calls and mostly worked with read and open requests. After I was done, it was possible to issue an open or read request for a file with an attached priority. That priority is used to calculate a bid for the request. If the disk is inactive, and the bid does not meet the entry price, the process sleeps. It will continue to sleep until more read requests are generated and the entry price is met, at which point it will be woken up. However, I didn't have time to do any work with write disk requests. The last week, Carla asked me to try to run some experiments and gather data. I found this to be one of the most trying parts of my experience. I was unable to gather conclusive data that showed that the new bidding system saved energy over the original ECOSystem implementation. Click here to see the few inconclusive numbers that I did get. After running all those test programs, though, I am pretty sure that my bidding process works.

What I Learned

Really, I think this summer was more about what I learned than what I accomplished for the Milly Watt Project. After all, 10 weeks isn't much time to learn how to hack the Linux kernel and gather experimental results. For starters, I learned a lot of commands in Unix that I had never used before. I learned how to use tar and gzip, how to compile the Linux kernel, and how to compile and load kernel modules. Since the Linux source is written in C, rather than C++, that was new for me, too. I learned tons about how reads, write, and buffer flushing actually happen in Linux, and how to write my own system calls (what a feeling of power!). Working on my web page was new for me, too. I taught myself about cascading style sheets and basically everything else, since, unbelievably, it was practically my first web page design experience. I guess its pretty amazing that in the midst of all that learning, I got anything done at all. Most importantly, I think, I learned how to teach myself things on my own. Or at least I got a little better at it.

Grad School

After doing this summer program, I still can't say that I have decided on graduate school. At this point, I don't think I have the desire to commit to 6 more years in a Ph.D. program. However, I'm not set against it, either. And I am very interested in completing a masters program. Still, I don't have any experience in industry either, so I may take a year and try that before deciding about graduate school. However, per Carla's advice, I am going to take the GRE's in the fall and keep my options open. She gave me good advice on schools to try to get into. It's nice to know somebody who has connections and is willing to write references. If you're interested in finding out about research, I think the DMP is a good idea. It can give you a good feeling for what it is like to do research as a graduate student with a professor riding backseat as advisor.