By Janie Chang
April 19, 2010 9:30 AM PT
Everyone understands the energy-saving benefits of shutting down PCs or leaving them on standby before leaving the office. The U.S. Environmental Protection Agency estimates that companies can achieve cost savings of $25 to $75 per PC annually if users activate system-hibernation features. The Gartner Group released a study in February 2009 which showed that a company with 2,500 PCs could save more than $40,000 a year simply by using power management. A Forrester report quotes companies saying they have cut greenhouse gas emissions by 65 percent and saved $3 million a year in electricity bills by going green in IT.
Power management is one of the simplest, most effective ways for a company to reduce energy bills, and operating systems, such as Windows 7, enable this by defaulting to sleep mode after an hour of idle time. Yet many corporate users will override this setting just in case they need after-hours remote access to their office PCs.
A research project called Greening Corporate Networks with Sleep Proxy, deployed for more than six months in Building 99, Microsoft Research’s Redmond headquarters, could offer a solution that lets more PCs sleep undisturbed overnight.
“The reality,” says Jitendra Padhye, senior researcher with Microsoft Research Redmond’s Networking Research Group, “is that habits are hard to change, so the ideal scenario is one where a desktop goes to sleep when not in use and awakens when the user needs to access it, without any need for the user to change behavior.”
Padhye—along with intern Joshua Reich of Columbia University and two members of Microsoft Research Redmond’s Networked Embedded Computing group: Michel Goraczko, senior research developer, and Aman Kansal, researcher—have developed a sleep-proxy solution that saves energy by enabling PCs in sleep mode to be available for remote network access; the PCs wake up only when needed. The core idea behind a sleep proxy is to enable a machine to sleep while the sleep proxy maintains the machine’s network presence.
The challenge for Padhye and his team was to build a practical sleep-proxy solution for deployment in a typical corporate network consisting of servers and desktop machines. The solution would have to support a usage scenario in which the user’s office PC goes to sleep and is awakened seamlessly and automatically when the user attempts a remote connection to log in or gain file access.
There were four goals for the Sleep Proxy solution:
While the notion of a sleep proxy is not new, evaluations of earlier work were based on small test beds or simulations. The Greening Corporate Networks with Sleep Proxy project is the first to deploy and evaluate a sleep-proxy solution in an enterprise environment with actual user machines; it provides valuable lessons that come from designing, building, deploying, and running a sleep-proxy system on a real network.
“Existing solutions and proposed approaches,” Padhye says, “have required either special hardware, or modifications to the operating system, or were confined to specific platforms. We felt that such requirements would create barriers to widespread deployment. Our approach aims to be general and requires neither extra hardware nor application modifications.”
The Sleep Proxy solution and results from the project were showcased in March during Microsoft Research’s TechFest 2010. The technical report, titled Sleepless in Seattle No Longer, co-authored by Reich, Goraczko, Kansal, and Padhye, will be presented in Boston in June during the 2010 USENIX Annual Technical Conference.
Sleep Proxy’s architecture is based on two main components: a server component called SleepServer, which is the proxy, and SleepNotifier, a program that runs on each client machine. Because of the IT environment, some details of the implementation are Windows-specific, but the entire architecture is designed to be operating-system-agnostic.
SleepNotifier alerts SleepServer just before the client goes to sleep, and SleepServer ensures that all incoming traffic meant for the client comes to the proxy instead. The proxy server’s role is to monitor traffic and respond accordingly. For some requests, it responds on behalf of the client so the client can continue sleeping, and others it ignores. Some traffic, such as a user access request, causes the SleepServer proxy to awaken the client and present the user with apparently seamless remote access.
“The advantage of this approach,” Padhye says, “is that it is entirely software-based, requires almost no hardware support, and doesn’t need a dedicated server. With a two-megabyte footprint, it has negligible CPU and network impact.”
Key to the solution’s deployment during the project was extensive instrumentation of the system, provided by a related Microsoft Research project, Joulemeter, a software-based mechanism that measures the energy consumption of systems and software by measuring the hardware resources—CPU, disk, memory, screen—being used and converting the data to actual power usage based on automatically learned, realistic power models. Thanks to Joulemeter’s sophisticated, model-driven power-measurement system, the team could dispense with generic estimates of PC power consumption and obtain far more accurate measurements of machine power consumption over the six-month project. The data enabled the team to capture details about sleep and wake-up periods: Why machines wake up, and why they stay up.
The 50 desktop users who participated in the project had few complaints about the eight- to nine-second initial delay time for remote access, which meant that the Sleep Proxy solution met the team’s goals for user acceptance. They found that the average PC sleeps more than 40 percent of the time and that most of the power savings came from longer, after-hours sleep periods.
Their data analysis yielded findings that took the team by surprise. Although the Sleep Proxy system enabled most clients’ machines to sleep more than 50 percent of the time, the average power savings was only 20 percent. It turned out that while user requests did awaken machines, it was the IT department that proved responsible for the majority of machine requests. IT server-connection attempts repeatedly woke sleeping machines, and in an extreme case, one server contacted a single machine more than 400 times over a two-week period.
The conclusion of the Sleep Proxy team was that, within the environment of the project, the solution itself had contributed significant energy savings, but even more significant energy savings were possible through changes to IT setups. For example, IT servers could coordinate and perhaps “rate-limit” how and when they wake machines and keep them awake.
Another real-world lesson came from the way Sleep Proxy affected cloud computing. Users provided feedback that the system interfered with the operation of two popular cloud-based applications, Live Mesh and Live Sync. The user’s machine is supposed to initiate a Transmission Control Protocol connection to the cloud server, which informs the machine of pending updates. The connection can be periodic or long-lived, but it must be initiated by the machine, which requires that the machine is awake.
In response to this feedback, the team built a manual wake-up Web portal that enables a user to awaken all machines that need to be synchronized.
“We tweaked the software to allow Sleep Proxy to work with these cloud applications,” Padhye says. “Incorporating true sleep-proxy functionality into cloud applications would clearly be the ideal solution and warrants further exploration, but this sort of experience is exactly what we needed to guide future design and deployment of sleep solutions in enterprise networks.”