Currentcy is a unifying abstraction and proportional energy use extends to all other devices on a platform. Currently, ECOSystem only explicitly manages the CPU, NIC, and disk subsystem. The resource managers of various devices must cooperate toward a common goal such as proportional energy use. Otherwise, a bottleneck device with some other policy objective can disrupt currentcy flow in general.
Given ECOSystem's currentcy model, tracking per-device consumption is straightforward for operations initiated via system calls. One particularly interesting challenge to achieving proportional energy use is managing the wireless network bandwidth, especially for incoming packets. The tricky issue for incoming traffic is that by the time a packet has been received and management actions can be applied, the energy to receive it has already been consumed in the wireless card. This makes it difficult to selectively receive packets destined for tasks with available currentcy as opposed to tasks without currentcy.
We modified the Linux network packet processing code to implement a work conserving proportional bandwidth allocation policy. Our scheme identifies flows whose associated tasks have consumed bandwidth beyond their currentcy-determined share and reduces their allocated bandwidth. Assuming other tasks can consume released bandwidth, this bandwidth reduction continues until all connections consume bandwidth in proportion to their task's energy share. This is accomplished by explicitly reducing the advertised window to reduce a task's available bandwidth.
To create a stressful condition for evaluation where the network is the bottleneck, we set the wireless ethernet card to 1Mbps. We execute RealPlayer, Netscape, and ijpeg with shares of 9000:3000:3000. Ijpeg serves as a CPU intensive application that does not compete for bandwidth but is capable of consuming 100% of the CPU. Realplayer plays a video clip rated at 550Kbs. Netscape continuously reloads a web page with five images with zero think time. When executing without energy constraints, RealPlayer consumes about 10643mW to execute without pauses in video playback, while Netscape consumes 3115mW, running unconstrained. Both RealPlayer and Netscape can consume all of the network bandwidth available.
In all of our network experiments we use the currentcy conserving energy allocation policy and constrain the total power consumption to 15000mW. Since network bandwidth is the bottleneck resource for RealPlayer and Netscape and none of the applications' energy needs are satisfied, the goal is to achieve proportional overall energy use after satisfying the constraints of proportional network bandwidth and network energy consumption. Table 2 presents results for three of the scheduler design points: 1) Our energy-centric CPU scheduler with the default TCP implementation, 2) the default Linux CPU scheduler with an energy-centric network scheduler, and 3) our combined energy-centric CPU and network schedulers. We omit the case where neither the CPU or network scheduler are energy-aware.
Our results show that the conventional network scheduler fails to provide either proportional network bandwidth or energy consumption. This is because Netscape is allowed to consume an unfair portion of network bandwidth. Netscape is able to take more than 50% of the bandwidth because it can open multiple connections. This reduces RealPlayer's ability to execute and produces an excess in currentcy that is reallocated to ijpeg. This results in ijpeg getting more of the CPU and consuming a much larger energy share than its intended allocation while the needs of the other applications are not satisfied (currentcy redistributed to ijpeg would be considered acceptable if the other applications had their needs appropriately met).
When we use an energy-centric network scheduler, but the default Linux CPU scheduler, we see that bandwidth and network power are consumed by RealPlayer and Netscape closer to the specified ratio of 3 to 1. However, RealPlayer still suffers from competition for the CPU with ijpeg which results in ijpeg significantly exceeding its energy share.
The most satisfying results are obtained by using energy-centric schedulers for both the CPU and network. Both network bandwidth and network energy are consumed proportionally by RealPlayer and Netscape. RealPlayer's share of the CPU is also protected from ijpeg by the energy-centric CPU scheduler. Netscape is throttled after receiving its share of network bandwidth (its bottleneck device) and can not consume the rest of its currentcy allocation. In this case, RealPlayer gets enough currentcy to meet its needs and execute without pausing.