Sometimes, the policy-makers in businesses don’t think through the full consequences of their policies. A recent tweet reminded me of one instance that appears to be fairly common, namely the company policy of powering off computers at the end of the day. If you’re a developer who has to spend time every day recovering from the consequences of this policy, here are some calculations that might allow you to explain it to your company’s management in terms that they understand: money.
For many job types, powering off computers at the end of the day may be appropriate, but for developers who may have reference material opened in Firefox, an IDE with multiple open tabs, maybe a time tracking application, maybe an IM client for collaborating with developers outside the company, it costs time for the computer, the OS, and the apps to be in the same state that they were before the computer was powered off. As developers are generally expensive, this loss of time can be viewed as a loss of money; you’re effectively paying your developers a higher hourly rate by building inefficiencies into their work process.
It’s understandable that the 16 hours between day end and day start are targeted in the interests of saving electricity, and the cost savings, while small as a percentage of any organization’s expenses, are easy to obtain. But let’s do some calculations to see if it makes sense to turn off a developer’s computer at the end of the day.
Scenario #0
The baseline, Scenario #0, is 100 developers leaving their computers powered on, but idle, 365 days a year. This costs electricity, but there is no impact to developer efficiency. Consider the baseline cost as $baseline, where developers spend $0 of their salaries recovering state. Any effort to save money will be compared with this state. Most nontechnical people would assume that any possible solution involving powering off unused equipment would save money, which is why so many nontechnical people advocate the “power off” policy.
Scenario #1
Scenario #1 will test the premise that powering off computers at the end of the work day saves money. I assume 100 developers shutting down their computers at the end of their work days. This costs less electricity than the baseline, but there is an impact to developer efficiency. Developers are assumed to work 250 days a year (50 weeks of work; 2 weeks of vacation; no working weekends). (I know this will amuse some developers, but the potential cost savings of powering down a computer are directly proportional to the number of days a developer works; if anything, I’m giving the idea a better chance.) 250 work days a year means that computers are unused for 16 hours a day during those 250 days and 24 hours a day during the remaining 115 days, for a total of 6760 hours a year.
The worst-case scenario I could find for average commercial utility cost was $0.1949 per kWhr, and that’s in Hawaii. So let’s use $0.20 per kWhr as the electricity cost. In order to know how much money it costs to keep a computer idle and powered on when it’s not used, we need to know how much power a computer draws when idle. My 3-year-old Core2 Duo laptop draws between 34W and 40W when idle. Let’s think the worst and imagine a computer that draws 100W when idle, more than doubling my real-world example. Such a computer would burn 676,000 Watt-hours (or 676 kWhrs) per year during its unused time, costing $135.20 per year for the portion of time in which it’s unused. If it were powered off during that time, the total savings over 100 developers would be $13,520 per year. Electricity cost in Scenario #1 would be $baseline – $13,520.
Let’s now consider the time involved. The best-case scenario for a useful developer may be ~$30,000 per year, though higher is surely more likely (especially in Hawaii). Let’s also figure that it takes 5 minutes, at best, to restore a powered-off computer to the state it was in before it was powered off. During our developer’s 250 annual work days, they spend 5 minutes recovering system and software state. This works out to ~20.83 hours a year. At $~14.42 per hour, a business could consider that, while they’re not paying a developer anything extra, $300.41 per year of their salary goes toward state recovery. In a company with 100 identical developers, this means that $30,041 per year is spent paying those 100 developers just to recover from their computers being powered off. Comparing with the baseline cost, this scenario costs $baseline – $13,520 + $30,041, or $16,521 more than the baseline of leaving the computers on all the time.
The technical among you are already shouting at your screen. What about suspend/hibernate options? You can suspend a computer to RAM, meaning you put it in a state where it sips only enough power to listen to a wakeup call while keeping its state alive. Scenario #2 considers what would happen if computers were put in a low-power state with fast recovery time, and Scenario #3 examines a no-power state with slower recovery time.
Scenario #2
My laptop suspends within 6 seconds, though the time cost does not factor in because I can just close the lid and walk away. While suspended, it sips 1W of power. It takes another 6 seconds to wake back up to its pre-suspend state. Assuming more worst-case scenario math, let’s say that it really takes 12 seconds to recover and sips 2W of power while suspended. If we re-use the other numbers above, the 100 computers in our fictional company would consume $270.40 in electricity per year when suspended making the electricity cost $baseline – $13,520 + $270.40, or $13,249.60 less than baseline cost. Likewise, our fictional company would pay their 100 developers $1200 to wait while their computer recovered state. This would make scenario #2 cost $12,049.60 less than $baseline.
Scenario #3
My laptop takes 50 seconds to hibernate, though it’s not necessary to wait around for it to finish. During hibernation, it uses exactly 0W of power to sustain state. It takes 110 seconds to wake back up to its pre-suspended state. Let’s make this worse and assume it really takes 5 minutes to recover. (I won’t increase the power consumption because there never is any in this state; it’s always 0W unless you’re using a laptop and the battery is charging.) Re-using the other numbers, the 100 computers in our fictional company would consume $0 in electricity per year when hibernating. Our 100 developers would spend $30,041 of their time to wait for their computers to recover state. Comparing the cost vs. the baseline, we have an electricity cost of $baseline – $13,520, and we have a developer cost of $30,041, which looks suspiciously like scenario #1 because 5 minutes of waiting for the computer to restore its state is equivalent to 5 minutes of developer time manually restoring its state.
I have simplified somewhat by not taking into account the time a powered-off computer takes to boot, either from a basic shutdown or from a state of hibernation, but if you extend my calculations to include that time, you’ll find that it merely amplifies my results or breaks ties in favor of state preservation. Likewise, using more realistic values for developer cost and for power consumption amplify the results.
Final Thoughts
It is never a good idea to have developers lose state. The best-case scenario is to suspend the state to RAM, and if your computers can’t do that, you need to make it happen.
Even with the highest electricity prices and unrealistically low developer salaries, the idea of abandoning computer state at the end of the day to save money does not work. However, even the best scenarios for saving money, from any angle, are insignificant when considered against a company’s total income and expenses. So why not just set a policy that improves workflow?
Costs, revisited
Scenario #0: $baseline
All computers left on 365 days a year, 24 hours a day
Developers spend no time saving/restoring state
Scenario #1: $baseline + $16,521
All computers powered off 16 hours a day during workdays and 24 hours a day during weekends and vacation
Developers spend 5 minutes a day restoring state manually
Scenario #2: $baseline – $12,049.60
All computers suspend state to RAM for 16 hours a day during workdays and 24 hours a day during weekends and vacation
Developers spend 12 seconds a day waiting for state to restore automatically
Scenario #3: $baseline + $16,521
All computers hibernate, saving state to disk, for 16 hours a day during workdays and 24 hours a day during weekends and vacation
Developers spend 5 minutes a day waiting for the computer to restore state automatically
Don’t forget the time involved in shutting down as well – saving open documents, closing programs, etc. It used to take me 5 or 10 minutes to shut down at the end of the day.
can you do a wake on lan command for suspended or hibernated system? We leave our PCs on at work so that windows admins can run nightly virus scans and push out system updates without the system bogging down during the day. if you could use wake on lan to wake the box up for this work, and suspend it again once that’s complete, you might have something.
As it is, I have the worst of both worlds. I have to log out of my system so updates get pushed out cleanly, but leave the computer running. If I reboot it and leave, it just sits at the encrypted disk login prompt and no updates are possible overnight. so I log out at the end of the day, and reboot first thing when I come in.
You need more to do.
Pam:
Saving documents takes time, but I wouldn’t include it as time wasted by the policy of shutting off the computer at the end of the day, because this is a necessary task regardless of power policy. When you’re finished saving open documents, the OS should take care of shutting down all your other applications for you, so it should be a “click and walk away” situation that should take about as long as initiating suspension or hibernation.
Jay:
When I worked at FedEx Ground, they pushed updates at noon, bringing our systems and network to a crawl. Mandatory automatic reboots would surprise us often when we returned from lunch. So many people think Windows has a low TCO because they don’t calculate the overhead involved in just keeping it running.
It looks like WOL works for either suspended or hibernated systems, according to this Windows-centric writeup: http://winhlp.com/node/57 I would assume that the same would be true for any hardware that supports WOL, regardless of OS, since WOL is initiated at the hardware level. As for re-hibernating or re-suspending, the solution would be OS-specific and would surely cost lots of time and money under Windows, as most things do; for a UNIX OS, it’d just be an ssh command to re-hibernate or re-suspend.
Nate:
It’s a combination of waking up too early and being bothered by people in positions of power making uninformed decisions that have consequences they do not grasp. Of course, this happens all the time, but it’s not often that such an easy example of mathematically-provable idiocy comes along 🙂
OK, I’ll concede that point. 🙂
WOL or a BIOS alarm to wake up at a certain time would be most ideal. I can imagine a scenario whereby just swiping your card to walk in the door would also send a WOL packet to your machine so it’s de-hibernated before you get to your desk.
Of couse, this ignores any outside activities needing to happen during off-hours (like virus scan, or other jobs running on the dev’s box), but those are much harder to compute.
Doug:
Holy maintenance, Batman! 🙂 I would guess that the R&D, deployment, and maintenance cost of the access card WOL mechanism would wipe out any savings it would have over just plain old suspend/resume.
To push updates or do scans of any kind, Jay’s concept of doing WOL from a central location, doing the remote work, and then forcing a re-suspend seems to be the most straightforward, until you think about doing this in Windows, which always wants to reboot when you change things.