Weekly Edition
Return to the Press page
| |||||||||||
Observations on power management
Matthew Garrett has posted some thoughts on power management. In many cases, the proper power management choices are counter-intuitive, so a collection of "best practices" is welcome. "The hardware used to display a static image on the screen is the same regardless of whether the image was generated with the graphics card's 2D or 3D hardware. Regardless of the number of graphical effects used on the desktop, the common case is for the desktop to be static. Composited and traditional desktops will generally consume the same amount of power."
(Log in to post comments)
Observations on power management Posted Nov 24, 2008 18:38 UTC (Mon) by tajyrink (subscriber, #2750) [Link]
Some little extra observations:
"Don't offer the choice of disabling compositing when on battery. It reduces functionality for no power benefit."
This one only becomes true with 2.6.28 or so, when all the vblank fixes in the drm drivers (intel and ati mainly) are in. Before it, it seems that composite/3D desktop triggers an amount of wakeups per second that equals the refresh rate, regardless of idleness. It's been fixed in drm trunk for over a year, but only with 2.6.28 the backlog started to really flow into Linus' kernel (I think. At least GEM went in.).
"Seeking takes more power than simply reading a linear set of blocks off a drive. It also kills performance - even a high spec drive will be unlikely to be able to perform more than 150 seeks a second."
I hope everyone developing eg. anything related to X, Compiz, KDE or GNOME startup reads this... otherwise we'll be stuck with the current boot+login time problems for the next 5-10 years until every root filesystem drive has been replaced with an SSD drive.
Observations on power management Posted Nov 24, 2008 18:47 UTC (Mon) by jwb (subscriber, #15467) [Link]
"A black screen takes up as much power on a TFT as a white one."
Almost true. A black image actually takes measurably more power than a white one on an LCD display. Black is the worst power state for a flat panel display. It would be better to simply turn off the backlight.
Observations on power management Posted Nov 24, 2008 20:17 UTC (Mon) by MattPerry (subscriber, #46341) [Link]
Can you provide a source to support that statement?
Observations on power management Posted Nov 24, 2008 20:27 UTC (Mon) by jwb (subscriber, #15467) [Link]
Here, let me google that for you:
http://techlogg.com/content/view/317/
And I've measured my own monitor as well. If you think about how an LCD works, it's logical that 100% black requires the highest current consumption in the panel.
Observations on power management Posted Nov 25, 2008 1:21 UTC (Tue) by sbergman27 (subscriber, #10767) [Link]
Yep. My 22" measures 26 watts while white and 27 watts while black. (My kill-a-watt only displays in increments of 1 watt.) I had always thought it would be the other way around. But now that I think about it, when a watch battery dies, the display turns all silver and not all black. It takes power to make black.
Backlights Posted Nov 25, 2008 15:30 UTC (Tue) by sladen (guest, #27402) [Link] The digital watch you're describing is using a simple LCD display (not a VFD/TFT/LED). If you were to flip the polarising glass over on the watch (more easily done on a household/school calculator) then you will have a display that default to black, with clear (reflected) writing. In a self-illuminated colour TFT display, the bright white backlight is used as a starting point, and selectively blocked out (meaning "black" never looks quite black). Transreflective screens complement the blacklight with reflected incoming light (as with the digital watch/calculator's primary source).
Finally, high-end recent flat-screen displays are now are able to selectively shut-off/tone down the output of the backlight in areas where the image is dark or black; by avoiding producing extra light in the first place, less of that light needs blocking to produce a satisfying black.
OLED? Posted Nov 26, 2008 15:39 UTC (Wed) by dmarti (subscriber, #11625) [Link] I'm saving up for an OLED monitor when those come out (the TV at the Sony store is beautiful). OLED doesn't have a backlight and AFAIK black is off.
Observations on power management Posted Nov 24, 2008 20:31 UTC (Mon) by pebolle (subscriber, #35204) [Link]
"It would be better to simply turn off the backlight."
Isn't that just what the author suggests: "Summary: If the user has not requested an animated screensaver, turn the screen off immediately rather than drawing a black screen."?
Observations on power management Posted Nov 24, 2008 20:33 UTC (Mon) by jwb (subscriber, #15467) [Link]
Yes, absolutely I agree. I was just trying to underscore the stupidity of the current batch of black screen "savers". For instance, Ubuntu by default still blacks out the screen for several minutes before disabling the backlight, as if this made any type of sense for today's computers.
Observations on power management Posted Nov 25, 2008 4:28 UTC (Tue) by Richard_J_Neill (subscriber, #23093) [Link]
> For instance, Ubuntu by default still blacks out the screen for several
> minutes before disabling the backlight, as if this made any type of sense > for today's computers.
Actually, this isn't as daft as it sounds. Apart from the disk, the LCD is the most likely thing to fail in a laptop - whether the backlight dies totally, or just dims or "yellows" over time. CCFL backlight life is hurt by both runtime and number of start-cycles. So, unless battery life is really really at a premium, you want to avoid turning off the backlight when the user is still actually using the machine.
Observations on power management Posted Nov 25, 2008 13:14 UTC (Tue) by renox (guest, #23785) [Link]
I disagree with you here: this doesn't make sense for the computer, but it make sense for the user.
If the user stays too long with doing anything the screen will idle to black and then the backlight will be disabled: it make sense to have an idle screen as quite often the user will move the mouse to re-activate it.
Should the idle screen be white or black?
Observations on power management Posted Dec 1, 2008 8:26 UTC (Mon) by MKallas (guest, #38539) [Link]
As soon as I lock the screen, the background light should turn dark.
Besides, my netbook uses a LED backlight so I don't have to care about dying cathodes. :-)
Observations on power management Posted Nov 24, 2008 21:07 UTC (Mon) by nix (subscriber, #2304) [Link]
Of course this only applies if you're displaying a screensaver image. If,
say, you're display an xterm (almost totally black, a bit of white text), turning off the backlight is a rather bad idea, and you just have to eat that tiny extra bit of power.
Observations on power management Posted Nov 25, 2008 3:17 UTC (Tue) by ncm (subscriber, #165) [Link]
Yet another argument for defaulting to black text on a white background: it doesn't just save your eyes, it saves power.
Observations on power management Posted Nov 25, 2008 13:48 UTC (Tue) by nix (subscriber, #2304) [Link]
Black text on a white background hurts my eyes (not surprising given that that means I'm basically staring into a light bulb).
Observations on power management Posted Nov 25, 2008 21:50 UTC (Tue) by ncm (subscriber, #165) [Link]
Turning down the brightness of the white background saves your eyes and saves power, too.
Observations on power management Posted Nov 27, 2008 12:30 UTC (Thu) by lysse (subscriber, #3190) [Link]
Contrast is a friend for those of us with dodgy eyesight.
I miss monochrome monitors; I don't suppose they're made any more, are they? A shame; I'd love to have a 600dpi monochrome A3-sized TFT on my desk - and given that 225dpi colour displays can be made, I think it's possible...
Observations on power management Posted Nov 24, 2008 19:09 UTC (Mon) by roblatham (subscriber, #1579) [Link] I'm surprised there was no mention of powertop... is that considered too geeky?==rob
Observations on power management Posted Nov 25, 2008 16:32 UTC (Tue) by saffroy (subscriber, #43999) [Link]
powertop would be "too geeky"? I would rather say "not geeky enough", considering that the article mentions disk seeks and mount options, but not laptop mode, for instance.
BTW powertop gives some interesting advice, eg. "enable laptop mode" or "use a kernel with NOHZ".
Observations on power management Posted Nov 24, 2008 19:15 UTC (Mon) by alecs1 (guest, #46699) [Link]
I think this has already been discussed here, but making the frequency go down can bring smaller voltages, and Matthew Garrett seems to be aware of it.
Wikipedia on SpeedStep:
Also, running at smaller frequencies may prevent the fans from spinning up, but I don't know how important that is.
Until I see benchmarks, I can't fully trust these CPU claims.
Observations on power management Posted Nov 24, 2008 19:44 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
Theoretically. In reality, the benefits aren't nearly that great. See Intel's figures at http://www.lesswatts.org/projects/applications-power-mana... , for instance.
Observations on power management Posted Nov 25, 2008 0:40 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] Your formula describes dynamic power from CMOS switching, assuming that everything operates on the same clock. However, these days leakage power is a major issue and can be as large as dynamic power.Since leakage power (roughly speaking) is linear in the voltage and isn't affected by the clock frequency, and since leakage power can be turned off by turning major hunks of the chip off, this tends to make it more effective to "race to idle" and turn the chip off than to voltage-scale. For some small embedded RISC processors the tradeoffs are different.
Wrong CPU! Posted Nov 25, 2008 11:30 UTC (Tue) by niner (subscriber, #26151) [Link]
What you describe is SpeedStep, which is available in Pentium M and Core CPUs. The
article talked about p4-clockmod, which handles Pentium 4 and Pentium 4-M CPUs, which _do not_ alter the voltages.
Ad Hominem Posted Nov 24, 2008 21:42 UTC (Mon) by ncm (subscriber, #165) [Link] It's time for an ad hominem remark: Matthew Garrett rocks. We need more of him. Fortunately, he was constructed in his present form in well under 30 years, so the lead time to construct a whole army of Matthews -- were the secret to his construction known -- is short enough not to be prohibitive.Biographical information, please, with emphasis on formative educational processes?
Ad Hominem Posted Nov 24, 2008 23:07 UTC (Mon) by sladen (guest, #27402) [Link] Whisky and Fruit flies. I think.
Ad Hominem Posted Nov 25, 2008 0:22 UTC (Tue) by ncm (subscriber, #165) [Link] Well, yes, but what kind of whiskeyed fruit flies?
Ad Hominem Posted Nov 25, 2008 0:41 UTC (Tue) by felixfix (subscriber, #242) [Link]
Inebriated, presumably.
Ad Hominem Posted Nov 25, 2008 1:35 UTC (Tue) by nix (subscriber, #2304) [Link]
Cambridge. It's the Chiark effect: the Ian Jackson hackish field.
Or something like that, anyway.
Ad Hominem Posted Nov 26, 2008 23:34 UTC (Wed) by BenHutchings (subscriber, #37955) [Link]
Much useful information can be found at http://angryfacts.com/
Taking a stand Posted Nov 25, 2008 4:23 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
Some of what needs to happen on issues like this is just a Debian-style stand on principle to eliminate problems even if this is briefly painful.
Beagle for example, survived early culls of awful software after Powertop by claiming that "soon" the Mono runtime would be fixed to eliminate its hopeless per-process (per-thread?) 10Hz timer that runs day & night, idle or busy. And once it had survived a few months this way, any feeling of urgency or even the vague idea that someone ought to /fix/ it went away, so here we are in November 2008, with people talking about the 2009 Linux distributions on the horizon, and not one of them seems to have "rip out Mono due to whale-murdering / wallet-emptying runtime" on its TODO list despite most of them talking about the importance of laptops & netbooks.
Taking a stand Posted Nov 25, 2008 10:38 UTC (Tue) by pharm (guest, #22305) [Link]
Ubuntu moved to tracker for their indexing system IIRC
Taking a stand Posted Nov 25, 2008 12:53 UTC (Tue) by Los__D (subscriber, #15263) [Link]
Ehm, my powertop seems to mark Tomboy (also uses the Mono runtime) as having around wakeups per second, and that is only when the window is visible (GTK# repainting needlessly maybe?).
It would seem like this is primarily an issue with Beagle, or that the Tomboy developers has found a way to eliminate the problem.
- Or that I'm on crack and reading the PowerTop output wrong?
Taking a stand Posted Nov 26, 2008 8:58 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
Well, a typo seems to have slipped into your comment, eliminating the key figure you were trying to communicate. But assuming it's a very small number, rather than say 10 which would just confirm what I said...
It's likely that this bug only affects Mono programs which use threads and can handle signals (merely dying when sent a signal doesn't require "handling") since the usual problem (seen and fixed in e.g. Python) seems to be that someone couldn't figure out how to reconcile POSIX signals with some Windows inspired threading in their design and resolved to just "poll" for signals. Personally I wouldn't have any confidence in a language runtime built by people who couldn't figure out the Right Thing but then I'm a C programmer so perhaps I'm just being a stick in the mud.
Taking a stand Posted Nov 26, 2008 9:15 UTC (Wed) by Los__D (subscriber, #15263) [Link]
Doh, that's what I get for taking time to check something, only to use a few seconds writing... :)
It was around 2 wakeups/second.
I don't know the cause, but let's see if they don't get it fixed.
Taking a stand Posted Nov 26, 2008 20:40 UTC (Wed) by ebirdie (subscriber, #512) [Link]
I have been hosting a Windows Server 2003 system running as a virtual machine on KVM. On the Windows system is run a .NET app with mysql backend. The .NET app is said to use threads heavily. The .NET app is having problems handling service requests in https. It is slow and drops connections even with minor load. The problem I have with it is that the developers of the app say that I am using a crappy Open Source virtual machine and not some "professional tool" like HyperV or VMware. :-)
Can anyone say here, could the above, what tialaramex described, have effects on KVM too ie. although there is a Windows system doing the threading and signaling "the right way", the VM hosting Linux kernel could have effect to native .NET runtime? Should I quote these comments from here and ask the same on KVM-devel list?
Taking a stand Posted Nov 27, 2008 17:30 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
My understanding is that this problem is in Mono, specifically, rather than being related to .NET per se.
Your situation is unfortunate but probably unrelated.
Taking a stand Posted Nov 27, 2008 4:52 UTC (Thu) by ncm (subscriber, #165) [Link] If to be a C programmer is to be a stick in the mud, then to be a C++ programmer is to stick a bee in the mud.
Observations on power management Posted Nov 27, 2008 21:11 UTC (Thu) by linusw (subscriber, #40300) [Link]
I already mailed the following remark to Matthew and just reposting here because there might be common interest:
I get the sense that this is for common Intel-like ACPI-controlled
Page 19 is especially interesting: they have implemented C-states,
C0 System executing code
OFF is really OFF as in power disconnected. So this is how they address
On top of that all peripherals are already powered down when not used
This is so far ahead of anything I've seen on the desktop, laptop etc,
Observations on (OMAP) power management Posted Dec 1, 2008 3:57 UTC (Mon) by HalfMoon (guest, #3211) [Link] OMAP processors come from cell phone designs, so they're pretty far ahead of what mainstream x86 processors -- or even SOCs -- do. They've got to stretch leetle tiny batteries out to a week of use. Accordingly they're pretty far ahead of most other embedded processors in terms of being optimized for low power consumptions. One big hangup for Linux is that so much of the power management work has been revolving around ACPI ... which has a lot of fairly broken concepts in those very low power concepts. One of the biggest being that it even makes *sense* to need separate system states like "suspend to memory". Those OMAP designs more or less aim at having that be the default system idle state. This isn't entirely unlike the OLPC model ... except OLPC was stuck with hardware designed to fit into an ACPI world, and which accordingly doesn't have good support for all that runtime power management. Devices tend to need long delays to get back to runnable states. The system doesn't really resume into a low power state, it resumes into a full power state and then -- if you're lucky! -- all the devices (and bridges etc) go into low power states right away It'll take a long time for x86 system design methodologies to adapt to the models used in OMAP. If they even can. Intel's ATOM stuff isn't aiming to be that power-efficient, and I can't think of any other companies in the x86 space who have the technical and market power to change the game that much.
|
|||||||||||