The GreenUp project provides a comprehensive energy/sleep monitoring and seamless wake up solution for a corporate network environment. Machines can be allowed to aggressively go to sleep safe in the knowledge that they can be seamlessly woken on-demand whenever they are accessed. By allowing machines to sleep more often significant energy savings can be achieved. Energy savings and usage can be readily monitored on the client as well as via a central database.
How does the sleep and wakeup work?
You should really read our paper and see the slides, but here is a brief summary. Every machine on a subnet runs a windows service, and they occasionally ping each other. Consider two machines A and B that are on the same subnet. When machine A falls asleep, machine B detects this, as A fails to respond to B's ping. B then sends a specially-crafted AP packet to the subnet router, asking it to redirect traffic meant for the A to B. Now, let's assume that a user tries to connect to the sleeping machine (i.e. to A) from some other machine (say, C) via RDP. The first packet would be a TCP SYN from C to A. This SYN would arrive at B. B would then wake machine A up by sending the "magic" Wake-on-LAN packet. As A wakes up, it informs the router to stop the redirection, and subsequent retransmits of the SYN from C arrive at A. From this point on, the connection proceeds as usual.
The key to note is that the wakeup process is completely transparent to the end user except for a brief delay, and requires no special software on C.
How does the energy monitoring work?
The energy monitoring is provided by a version of Joulemeter.
- Siddhartha Sen, Jacob R. Lorch, Richard Hughes, Carlos Garcia Jurado Suarez, Brian Zill, Weverton Cordeiro, and Jitendra Padhye, Don’t Lose Sleep Over Availability: The GreenUp Decentralized Wakeup Service, in Proceedings of the 9th USENIX Symposium on Networked Systems Design and Implementation (NSDI), USENIX, April 2012
- Joshua Reich, Michel Goraczko, Aman Kansal, and Jitu Padhye, Sleepless In Seattle No Longer, in USENIX Annual Technical Conference, USENIX, 22 June 2010