Wow. Impressive (and answers a few questions I’ve had over the years), but this definitely reminds me of that early 2000s article: “How I managed to enable audio in Linux, in only 703 simple steps and with just a few kernel modifications.” With so many consumer devices now built on Linux, one would have assumed that solid sleep support (including hardware ARP support) would have made it back into the distributions by this point.
The building blocks have been around for ages. The idle detection would not work for me, because I often leave idle ssh sessions in the background. I use autossh so that my laptop reconnects when it wakes up and use the persisitent UUID that the macOS Terminal provides in an environment variable so that they can reconnect to the same place after the laptop reboots, but I’m weird.
I’ve been expecting the WoL + mDNS-SD combination to be supported by consumer routers for around 15 years. It would be pretty trivial to make transparent. The router receives the mDNS responses from everything and knows the IP and MAC already. It could wait for mDNS requests and just send a WoL packet to any device that had a useful response to a previous request and see if it responds. There probably just isn’t sufficient demand: not many consumer devices accept local network connections (printers are probably the only common exception).
Based on my own home-server observations (via the APC-UPS monitoring), the largest power consumption components are active rotational disks; if my UPS is at ~15-20% load when idle (and this includes the desktop, switch, router, and a few other gadgets), starting any kind of I/O (on a 3 disk RAID5), jumps it with another 10% or more.
Thus, a first step in power consumption is making sure rotational disks go to sleep when not needed. (Not to mention they are the primary source of background noise…)
I’ve configured mine to suspend after 12 minutes of inactivity. And care must be taken that they are specifically built for this purpose (i.e. NAS or enterprise drives) or else their life would be greatly reduced…
I have no doubt there is a power savings, considering things like disk power consumption you mentioned. However, the net power savings is not just how much you saved by turning the main device off. The extra network gear (the special kind that requires port mirroring), the raspberry pi (minimal), the extra power required while the main server wakes up and re-syncs it’s state (and disks). All of these take away from the net power savings, and I would bet that if the computer is waking up “too often” that you would lose most of your savings.
Power savings aside, I’ve read that disks starting and stopping is the time they are most likely to fail - so this setup may significantly reduce the life span of disks, which also reduces the cost savings.
Not trying to cast shade in this article, it’s a really cool write-up. I’d just like to see the other data that takes this from a cool concept to a justifiable improvement.
Power savings aside, I’ve read that disks starting and stopping is the time they are most likely to fail - so this setup may significantly reduce the life span of disks, which also reduces the cost savings.
Indeed, desktop grade disks weren’t meant to be spun up/down repeatedly (I had a WD Black disk that I think died because of this reason). However, I think it makes no difference (with regard to disk wear-and-tear) putting only the disks on standby or putting the whole system on standby. (In fact, many consumer disks do this automatically these days.)
Thus the article tackles mainly the idle host power consumption.
I’ve done something like this before! It’s an education.
I also bought a low-power server I leave on all the time, exactly so I don’t have to do this anymore. If a smol Ryzen APU can’t handle a job, it’s a job that can wait until I get home and push the power button on my desktop.
I doubt I will ever do this given that my servers are tiny single board Intel jobs with teeny wattage but knowing how is half the battle and I have thought about getting an Intel NUC or something a smidge larger someday so having this around could be very handy for that eventuality.
Wow. Impressive (and answers a few questions I’ve had over the years), but this definitely reminds me of that early 2000s article: “How I managed to enable audio in Linux, in only 703 simple steps and with just a few kernel modifications.” With so many consumer devices now built on Linux, one would have assumed that solid sleep support (including hardware ARP support) would have made it back into the distributions by this point.
The building blocks have been around for ages. The idle detection would not work for me, because I often leave idle ssh sessions in the background. I use autossh so that my laptop reconnects when it wakes up and use the persisitent UUID that the macOS Terminal provides in an environment variable so that they can reconnect to the same place after the laptop reboots, but I’m weird.
I’ve been expecting the WoL + mDNS-SD combination to be supported by consumer routers for around 15 years. It would be pretty trivial to make transparent. The router receives the mDNS responses from everything and knows the IP and MAC already. It could wait for mDNS requests and just send a WoL packet to any device that had a useful response to a previous request and see if it responds. There probably just isn’t sufficient demand: not many consumer devices accept local network connections (printers are probably the only common exception).
I would love to see the net change in power consumption with this setup.
Based on my own home-server observations (via the APC-UPS monitoring), the largest power consumption components are active rotational disks; if my UPS is at ~15-20% load when idle (and this includes the desktop, switch, router, and a few other gadgets), starting any kind of I/O (on a 3 disk RAID5), jumps it with another 10% or more.
Thus, a first step in power consumption is making sure rotational disks go to sleep when not needed. (Not to mention they are the primary source of background noise…)
I’ve configured mine to suspend after 12 minutes of inactivity. And care must be taken that they are specifically built for this purpose (i.e. NAS or enterprise drives) or else their life would be greatly reduced…
I have no doubt there is a power savings, considering things like disk power consumption you mentioned. However, the net power savings is not just how much you saved by turning the main device off. The extra network gear (the special kind that requires port mirroring), the raspberry pi (minimal), the extra power required while the main server wakes up and re-syncs it’s state (and disks). All of these take away from the net power savings, and I would bet that if the computer is waking up “too often” that you would lose most of your savings.
Power savings aside, I’ve read that disks starting and stopping is the time they are most likely to fail - so this setup may significantly reduce the life span of disks, which also reduces the cost savings.
Not trying to cast shade in this article, it’s a really cool write-up. I’d just like to see the other data that takes this from a cool concept to a justifiable improvement.
Indeed, desktop grade disks weren’t meant to be spun up/down repeatedly (I had a WD Black disk that I think died because of this reason). However, I think it makes no difference (with regard to disk wear-and-tear) putting only the disks on standby or putting the whole system on standby. (In fact, many consumer disks do this automatically these days.)
Thus the article tackles mainly the idle host power consumption.
I’ve done something like this before! It’s an education.
I also bought a low-power server I leave on all the time, exactly so I don’t have to do this anymore. If a smol Ryzen APU can’t handle a job, it’s a job that can wait until I get home and push the power button on my desktop.
What a beautifully detailed write-up!
I doubt I will ever do this given that my servers are tiny single board Intel jobs with teeny wattage but knowing how is half the battle and I have thought about getting an Intel NUC or something a smidge larger someday so having this around could be very handy for that eventuality.