Last week, I posted a note about a new sleep management system, developed by Microsoft Research, which provides a mechanism to use the sleep state, common in modern PCs, to save energy in a managed way on a network. Now there is a report on the PhysOrg.com site about another approach to tackling the same problem. The SleepServer system, developed by computer scientists at the University of California, San Diego, has many features similar to the Microsoft system I discussed before; yet there are some key differences that make it worth examining. SleepServer is described in a paper [PDF download] to be presented at the USENIX Annual Technical Conference in Boston this week.
Like the Microsoft Research system, SleepServer uses a sleep proxy, running on a server, to stand in for each sleeping client machine. The overall SleepServer system is managed by the SSR-Controller application, running on the server. Each managed client machine has a SSR-Client application running, which does two things: it keeps the SSR-Controller informed of the client’s current “network state” (e.g., on which ports it is listening), and it informs the SSR-Controller when the client is about to enter the sleep state. When the client goes to sleep, the SSR-Controller sets up the sleep proxy to stand in for it, using gratuitous ARP probes to redirect traffic to the client’s IP address to the proxy.
So far, this is almost the same as the Microsoft system. What makes SleepServer different is that the proxy is not just an application that processes network requests; it is a virtual machine image of the client, running under a hypervisor (virtual machine monitor), such as Xen. This potentially is a more powerful solution, since the images can obviously reflect idiosyncratic characteristics of individual clients; the images can also incorporate what the authors call “stub applications” — minimal but functional versions of real applications running on the client. (For example, a long-running data transfer might continue to run in the virtual machine, using only the data communications “core” of the application, without any user interface.) Potentially, this approach provides more flexibility, if the network’s owner is willing to expend some effort in customization. It also is more suitable for use in a mixed-platform environment, since network profiles and responses can be tailored at the client level.
The authors claim that their tests demonstrate that the SleepServer system can achieve significant energy savings in a real network environment.
We detail results from our experience in deploying SleepServer in a medium scale enterprise with a sample set of thirty machines instrumented to provide accurate real-time measurements of energy consumption. Our measurements show significant energy savings for PCs ranging from 60%-80%, depending on their use model.
Probably there is no “one size fits all” approach to managing network “sleep” that applies to all environments; but it is good to see that some thoughtful work is being done on the problem.