some ruminations on saving money, power, etc.

[tmetro-blu-5a1Jt6qxUNc at public.gmane.org (Tom Metro)]

Dan Ritter wrote:
> - my desktop, which never sleeps
...
> The...machines that don't sleep, aren't sleeping because I can't get
> them to sleep.

Figuring out why the desktop doesn't sleep sounds like it would provide
the best payoff for the least cost outlay. Time cost is another matter...

I can sympathize, as I've never invested the time in getting sleep mode
working on my Acer laptop running Ubuntu. What's worse is that the
display backlight ceased powering down a few months ago. Unless you make
regular use of battery power, there isn't enough short-term benefit to
justify the time investment.

Linux seems to be notorious for having partially or nit working power
saving features, and I suspect there are a lot of systems wasting power
because the users can't be bothered figuring out what needs to be tweaked.


> The server can't and shouldn't sleep...
> Myth box don't sleep because they need to be awake. 

Maybe you can spin down the disks? (Probably only of marginal benefit.
10 or 15 watts down to 2 or 3 watts?) Switch to "green" (low RPM) drives
on your next capacity upgrade?

How about enabling frequency scaling on the CPU? Or if your CPU doesn't
support it, maybe it's possible to upgrade to a newer CPU, while keeping
the remainder of the hardware. That way you leverage the most power
savings for the least investment.

I know the Athlon in my MythTV server doesn't support it, as the start
up scripts complain about the lack of support on bootup.

Have you considered consolidating your main and MythTV servers? (I hear
some people have even had success running MythTV in a VM.)


> There is a timed wakeup function on some motherboards;

WOL packets sent from another box (like a router; see other message) is
probably more manageable. But I can't see taking the effort to manually
synchronize wakeup packets with the MythTV scheduler. To do this right
you'd need to build some software that queries the scheduler for
upcoming recording times, looking for gaps large enough to be worth the
effort of shutting down, and then scheduling a wakeup task on another
box. It wouldn't be that hard to do, and I bet someone has already built it.

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/