Observations on power management
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."
Posted Nov 24, 2008 18:38 UTC (Mon)
by tajyrink (subscriber, #2750)
[Link]
"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.
Posted Nov 24, 2008 18:47 UTC (Mon)
by jwb (guest, #15467)
[Link] (15 responses)
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.
Posted Nov 24, 2008 20:17 UTC (Mon)
by MattPerry (guest, #46341)
[Link] (4 responses)
Posted Nov 24, 2008 20:27 UTC (Mon)
by jwb (guest, #15467)
[Link] (3 responses)
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.
Posted Nov 25, 2008 1:21 UTC (Tue)
by sbergman27 (guest, #10767)
[Link] (2 responses)
Posted Nov 25, 2008 15:30 UTC (Tue)
by sladen (guest, #27402)
[Link] (1 responses)
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.
Posted Nov 26, 2008 15:39 UTC (Wed)
by dmarti (subscriber, #11625)
[Link]
Posted Nov 24, 2008 20:31 UTC (Mon)
by pebolle (guest, #35204)
[Link] (4 responses)
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."?
Posted Nov 24, 2008 20:33 UTC (Mon)
by jwb (guest, #15467)
[Link] (3 responses)
Posted Nov 25, 2008 4:28 UTC (Tue)
by Richard_J_Neill (subscriber, #23093)
[Link]
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.
Posted Nov 25, 2008 13:14 UTC (Tue)
by renox (guest, #23785)
[Link] (1 responses)
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?
Posted Dec 1, 2008 8:26 UTC (Mon)
by MKesper (subscriber, #38539)
[Link]
Posted Nov 24, 2008 21:07 UTC (Mon)
by nix (subscriber, #2304)
[Link] (4 responses)
Posted Nov 25, 2008 3:17 UTC (Tue)
by ncm (guest, #165)
[Link] (3 responses)
Posted Nov 25, 2008 13:48 UTC (Tue)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Nov 25, 2008 21:50 UTC (Tue)
by ncm (guest, #165)
[Link] (1 responses)
Posted Nov 27, 2008 12:30 UTC (Thu)
by lysse (guest, #3190)
[Link]
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...
Posted Nov 24, 2008 19:09 UTC (Mon)
by roblatham (guest, #1579)
[Link] (1 responses)
==rob
Posted Nov 25, 2008 16:32 UTC (Tue)
by saffroy (guest, #43999)
[Link]
BTW powertop gives some interesting advice, eg. "enable laptop mode" or "use a kernel with NOHZ".
Posted Nov 24, 2008 19:15 UTC (Mon)
by alecs1 (guest, #46699)
[Link] (3 responses)
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.
Posted Nov 24, 2008 19:44 UTC (Mon)
by mjg59 (subscriber, #23239)
[Link]
Posted Nov 25, 2008 0:40 UTC (Tue)
by JoeBuck (subscriber, #2330)
[Link]
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.
Posted Nov 25, 2008 11:30 UTC (Tue)
by niner (subscriber, #26151)
[Link]
Posted Nov 24, 2008 21:42 UTC (Mon)
by ncm (guest, #165)
[Link] (5 responses)
Biographical information, please, with emphasis on formative educational processes?
Posted Nov 24, 2008 23:07 UTC (Mon)
by sladen (guest, #27402)
[Link] (2 responses)
Posted Nov 25, 2008 1:35 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Or something like that, anyway.
Posted Nov 26, 2008 23:34 UTC (Wed)
by BenHutchings (subscriber, #37955)
[Link]
Posted Nov 25, 2008 4:23 UTC (Tue)
by tialaramex (subscriber, #21167)
[Link] (7 responses)
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.
Posted Nov 25, 2008 10:38 UTC (Tue)
by pharm (guest, #22305)
[Link]
Posted Nov 25, 2008 12:53 UTC (Tue)
by Los__D (guest, #15263)
[Link] (5 responses)
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?
Posted Nov 26, 2008 8:58 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link] (4 responses)
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.
Posted Nov 26, 2008 9:15 UTC (Wed)
by Los__D (guest, #15263)
[Link]
It was around 2 wakeups/second.
I don't know the cause, but let's see if they don't get it fixed.
Posted Nov 26, 2008 20:40 UTC (Wed)
by ebirdie (guest, #512)
[Link] (1 responses)
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?
Posted Nov 27, 2008 17:30 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link]
Your situation is unfortunate but probably unrelated.
Posted Nov 27, 2008 4:52 UTC (Thu)
by ncm (guest, #165)
[Link]
Posted Nov 27, 2008 21:11 UTC (Thu)
by linusw (subscriber, #40300)
[Link] (1 responses)
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,
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.
Observations on power management
Observations on power management
Observations on power management
Observations on power management
http://www.g4techtv.ca/callforhelp/shownotes/0283.shtml?r...
Observations on power management
Backlights
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.
OLED?
Observations on power management
Observations on power management
Observations on power management
> minutes before disabling the backlight, as if this made any type of sense
> for today's computers.
Observations on power management
There's a power usage reason for it to be white for LCD, but there's also a 'do not distract the user' reason to use black as when the backlight will be disabled the user won't notice an annoying white to black flickering.
Observations on power management
Besides, my netbook uses a LED backlight so I don't have to care about dying cathodes. :-)
Observations on power management
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
Observations on power management
Observations on power management
Observations on power management
I'm surprised there was no mention of powertop... is that considered too geeky?
Observations on power management
Observations on power management
Observations on power management
"P = C(V^2)f
[...] For example, for a 1.6 GHz Pentium M, the clock frequency can be stepped in 200 MHz increments over the range from 1.6 to 0.6 GHz. At the same time, the voltage requirement decreases from 1.484 V to 0.956 V. The result is that the power consumption theoretically goes down by a factor 6.4.".
The article goes on an aknoledges that this is only a teoretical computation.
Observations on power management
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.
Observations on power management
Wrong CPU!
article talked about p4-clockmod, which handles Pentium 4 and Pentium 4-M CPUs,
which _do not_ alter the voltages.
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.
Ad Hominem
Whisky and Fruit flies. I think.
Ad Hominem
Ad Hominem
Ad Hominem
Taking a stand
Taking a stand
Taking a stand
Taking a stand
Taking a stand
Taking a stand
Taking a stand
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.
Taking a stand
Observations on power management
components, but have you seen the stuff Texas Instruments implemented in
the OMAP3430 embedded processor? I attended a demo of this at the CELF
embedded Linux conference in april and it was quite impressive, there is
a presentation here (powerpoint, not my fault):
http://www.celinux.org/elc08_presentations/TI_OMAP3430_Li...
however these have platform-specific meanings:
C1 MPU WFI + Core active + No tick suppression
C2 MPU WFI + Core active + Tick suppression
C3 MPU CSWR + Core active + Tick suppression
C4 MPU OFF + Core active + Tick suppression
C5 MPU RET + Core RET + Tick suppression
C6 MPU OFF + Core RET + Tick suppression
C7 MPU OFF + Core OFF + Tick suppression
submicron technologies with increased leakage.
(even for very very short intervals, ms range) this is called "OFF
mode".
so I think it's interesting because that's where I think the common
equipment must be in just a few years.
Observations on (OMAP) power management