All this complexity to save a few bucks per year on your electricity bill? This is ridiculous, the Pi costs far more than what you can be expected to save.
replies(9):
(For example, imagine a big home GPU server that is needed only intermittently, and you want it to spin up automatically on network traffic from family's various devices that you can't modify.)
Of course, if you have simpler needs, and you're willing to send a WOL magic packet from the using devices, you can do in a few lines of shell script. It's a 1-line ssh-to-something-that-can-etherwake-on-that-vlan script, then wait in a loop for the service you need to appear, then 1-line ssh-to-server-to-shutdown when you're done.
Anyway it's not about the money for me it's any the aesthetics. Burning power for nothing is yucky.
Edit: just been Googling around. OP is running one of these HP mini PCs. They are pretty efficient! Some go well below 10W. So yeah I would say for the specific use case it's unlikely to matter very much. But still it's a useful thing to be able to do in general.
I guess everyone has to go through it.
Fortunately, the author wrote a derailed essay explaining all of this…
> You should never add more failure points to infra, ever.
Every time you add a new system or a new feature you necessarily “add more failure points”, there's no way around that.
One should avoid introducing more failure points than needed for the functionality you want, that's it.
You say it's a “solved problem”, but you only give solutions to a different problem (starting the server at a scheduled time, when the author wants to start the server on demand).
If you are willing to send magic packets to wake up the server, before using it, you can save money from the electricity bill with negligible complexity.
(I also heard that it sometimes suggests power saving modes that are usually switched off for a good reason, like apparently you really don't want some USB controllers going into certain sleep modes as they take seconds to come back).
Looking at powertop, the various qemu virtual machines have high events/sec compared to host processes. There are also a couple of timers - tick_nohz_handler and hrtimer_wakeup - which seem to generate hundreds of events per second.