Question on power consumption of zen-updater and opensuseupdater / kernel - powersaving options
Dear listmembers, when trying to optimize openSUSE 10.2 on my X60 (please see http://www.thinkwiki.org/wiki/Installing_openSUSE_10.2_on_a_ThinkPad_X60 for my findings) I stumbled over some "Ungereimtheiten" - please translate whoever can :-): 1.) Both zen-updater and opensuseupdater continuously keep loading the battery through wakeup events - IMHO one event every hour should be more than enough for such a tool. 2.) The kernel lacks several settings for optimizing the power consumption, these are specifically: CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_USB_SUSPEND=y For powertop: CONFIG_TIMER_STATS=y Why aren't those activated? Stability issues? Activating the kernel parameters and playing around with powertop brought me from ~15W power consumption in battery operation mode down to ~10W (lenovo thinkpad). This is something other laptop users might want to profit from. Any comments? Should I open bug reports for these? Thank you very much, take care Dieter Jurzitza -- ----------------------------------------------------------- | \ /\_/\ | | ~x~ |/-----\ / \ /- \_/ ^^__ _ / _ ____ / <°°__ \- \_/ | |/ | | || || _| _| _| _| if you really want to see the pictures above - use some font with constant spacing like courier! :-) ----------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-mobile+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mobile+help@opensuse.org
On Mon, 2007-07-09 at 16:33 +0200, Dieter Jurzitza wrote:
Dear listmembers, when trying to optimize openSUSE 10.2 on my X60 (please see http://www.thinkwiki.org/wiki/Installing_openSUSE_10.2_on_a_ThinkPad_X60 for my findings) I stumbled over some "Ungereimtheiten" - please translate whoever can :-):
1.) Both zen-updater and opensuseupdater continuously keep loading the battery through wakeup events - IMHO one event every hour should be more than enough for such a tool. Could you give us a pointer what kind of events happen how often, pls. And how they keep loading the battery. Through not going into Cx state or because CPU load is that high that even frequency is set to higher freqs.
2.) The kernel lacks several settings for optimizing the power consumption, these are specifically:
CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_USB_SUSPEND=y
For powertop: CONFIG_TIMER_STATS=y
Why aren't those activated? Stability issues? Because they were introduced in 2.6.21 and 10.2 is 2.6.18 based. But you are right they are even not set in 10.3 (yet). Not sure whether CONFIG_NO_HZ is already stable enough.
Activating the kernel parameters and playing around with powertop brought me from ~15W power consumption in battery operation mode down to ~10W (lenovo thinkpad). This is something other laptop users might want to profit from.
Any comments? Should I open bug reports for these? Is it really that much? What have you modified? Simply booting the one or the other kernel saves you that much (-> I doubt that)? Do you use an USB mouse/keyboard that gets autosuspended with the other kernel?
How much does CONFIG_NO_HZ really give you if you optimize user space progs for both kernels? This is really interesting. Please be careful to document any changes and only try to compare one change with another or figures are useless. E.g.: - With zen-updater and opensuseupdater events disabled I save xy. - With CONFIG_NO_HZ I save yx. And only change these to have comparable values. Also an initial setup with relevant data might be useful. E.g. cat /proc/acpi/processor/*/power (or the new C-state interface), USB devices are evil, display backlight was on/off and whatever could have to do with power saving. Thanks, Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-mobile+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mobile+help@opensuse.org
Dear Thomas, dear listmembers, I know I owe answers (specifically to Thomas), so here you go: "Stock" kernel 2.6.21-185 (not in use any more, stem from kernel repositories at that time: Backlight full power, ipw3945 full power mode: 15,7 Watts power consumption (average) "Modified" kernel 2.6.21-190 (derived from above, only the following options activated: CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_USB_SUSPEND=y CONFIG_TIMER_STATS=y Backlight full power, ipw3945 full power mode: 12,6 Watts. Backlight full power, ipw3945 in low power consumption mode: 11,4 Watts. Backlight totally dimmed and ipw3945 in low power mode: 9,5 Watts so yes, you were right, the kernel options are not _that_ effective. But three Watts still remain an impressive value. What you say about stability of the kernel options - well, I can tell for my laptop only that since the day I switched to this kernel including the options mentioned above I haven't seen a single crash - the issues I had been facing before were mainly related to suspend issues. Nevertheless from my limited scope of view these options seem to do no harm - and a commenter in the wiki said that Ubuntu and Fedora would acitvate them by default. What regards the loading induced by zen-updater and opesuseupdater I will provide a follow-up soon. And, sorry, it would take tons of time to rebuild the kernel with each option activated separately to distinguish what contributes how much. If there is no urgent need for this I would be glad if you can survive without that information. Come back to me if you really really need it - and tell me the activation sequence you'd want to see. Hope this helps, sorry for the delay, take care Dieter Am Dienstag, 10. Juli 2007 19:54 schrieb Thomas Renninger: ****
Could you give us a pointer what kind of events happen how often, pls. And how they keep loading the battery. Through not going into Cx state Is it really that much? What have you modified? Simply booting the one or the other kernel saves you that much (-> I doubt that)? Do you use an USB mouse/keyboard that gets autosuspended with the other kernel?
-- ----------------------------------------------------------- | \ /\_/\ | | ~x~ |/-----\ / \ /- \_/ ^^__ _ / _ ____ / <°°__ \- \_/ | |/ | | || || _| _| _| _| if you really want to see the pictures above - use some font with constant spacing like courier! :-) ----------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-mobile+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mobile+help@opensuse.org
On Wed, 2007-07-25 at 13:47 +0200, Dieter Jurzitza wrote:
Dear Thomas, dear listmembers, I know I owe answers (specifically to Thomas), so here you go:
"Stock" kernel 2.6.21-185 (not in use any more, stem from kernel repositories at that time: Backlight full power, ipw3945 full power mode: 15,7 Watts power consumption (average)
"Modified" kernel 2.6.21-190 (derived from above, only the following options activated: CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_USB_SUSPEND=y CONFIG_TIMER_STATS=y
Backlight full power, ipw3945 full power mode: 12,6 Watts.
Backlight full power, ipw3945 in low power consumption mode: 11,4 Watts.
Backlight totally dimmed and ipw3945 in low power mode: 9,5 Watts
so yes, you were right, the kernel options are not _that_ effective. But three Watts still remain an impressive value. What you say about stability of the kernel options - well, I can tell for my laptop only that since the day I switched to this kernel including the options mentioned above I haven't seen a single crash - the issues I had been facing before were mainly related to suspend issues. Nevertheless from my limited scope of view these options seem to do no harm - and a commenter in the wiki said that Ubuntu and Fedora would acitvate them by default.
What regards the loading induced by zen-updater and opesuseupdater I will provide a follow-up soon.
And, sorry, it would take tons of time to rebuild the kernel with each option activated separately to distinguish what contributes how much. If there is no urgent need for this I would be glad if you can survive without that information. Come back to me if you really really need it - and tell me the activation sequence you'd want to see. Dieter, thanks a lot. Such values are really helpful and cost a lot of time to do...
Just one question: Have you used an USB device while doing this? Hmm, you could have some built in USB device... What I like to find out: USB suspend works, AFAIK: if an USB suspend capable device is unused for a specific time, it's suspended (after 2 seconds per default). The kernel does not need to poll it every some micro seconds (yes USB is stupid) and therefore the C-states are much more efficient. It wakes up itself if it gets used again by an interrupt. E.g. if you do not use your (new enough) mouse for 2 seconds, it's suspend and not functional any more. If you hit a specific button (the one in the middle normally), the mouse generates an interrupt, the device gets polled again and works, but the processor consumes more power (because it's not going to C-states that often anymore). Could you somehow find out whether it was the USB autosuspend kicking in, suspending a device or whether it's the NO_HZ option? Maybe you can simply use your low energy kernel (I expect you use it by default :) ) and disable autosuspend (find /sys |grep autosuspend) and echo -1 > into the found files..., then autosupend should not kick in for sure. Hmm, I doubt a USB device got suspended, if you don't find the time to do this, then just don't care... Maybe you have another idea to find out or if anything additional comes to your mind about these values, I'd be happy to know. BTW: Maybe you've already noticed, CONFIG_TIMER_STATS is enabled in our very recent kernels (Alpha6 should already be compiled with that one). Ahh yes, how many C-states does your processor support? Could you post /proc/acpi/processor/*/power Thanks, Thomas
Dieter
Am Dienstag, 10. Juli 2007 19:54 schrieb Thomas Renninger: ****
Could you give us a pointer what kind of events happen how often, pls. And how they keep loading the battery. Through not going into Cx state Is it really that much? What have you modified? Simply booting the one or the other kernel saves you that much (-> I doubt that)? Do you use an USB mouse/keyboard that gets autosuspended with the other kernel?
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-mobile+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mobile+help@opensuse.org
Dear listmembers, dear Thomas, here comes the comment about zen-updater. It contributes by about 5% to the wakeup events - though the power consumption is not high - I doubt that this should be the case. What is even more boring: you cannot end zen-updater, if you say "end" it simply does not stop - it is like a barnacle that does not want to stop. Opensuse-updater behaves similarly. And again, I can hardly see a need for a software updater to generate so much noise ;-) What regards the power state capability of my computer - lenovo X60 - see below: active state: C3 max_cstate: C8 bus master activity: 00000000 maximum allowed latency: 8000 usec states: C1: type[C1] promotion[C2] demotion[--] latency[001] usage[ 00000010] duration[00000000000000000000] C2: type[C2] promotion[C3] demotion[C1] latency[001] usage[ 00019637] duration[00000000000320989970] *C3: type[C3] promotion[--] demotion[C2] latency[057] usage[ 00163901] duration[00000000005856338283] /home/exchange> cat dummy active state: C3 max_cstate: C8 bus master activity: 00000000 maximum allowed latency: 8000 usec states: C1: type[C1] promotion[C2] demotion[--] latency[001] usage[00000010] duration[00000000000000000000] C2: type[C2] promotion[C3] demotion[C1] latency[001] usage[00019637] duration[00000000000320989970] *C3: type[C3] promotion[--] demotion[C2] latency[057] usage[00163901] duration[00000000005856338283] Take care Dieter ******************************************************************************** PowerTOP version 1.6 (C) 2007 Intel Corporation Cn Verweildauer (5s) Mittlere Verweildauer C0 (Prozessor läuft) ( 2,9%) C1 0,0ms ( 0,0%) 0,0ms C2 5,3ms ( 1,5%) 5,3ms C3 6,0ms (95,6%) 6,0ms Aufwachen pro Sekunde : 162,4 Stromverbrauch (nach ACPI): 9,4W (3,3 Std.) Häufigste Ursachen für das Aufwachen: 46,6% ( 90,8) <interrupt> : i8042 16,3% ( 31,8) <interrupt> : uhci_hcd:usb2, yenta,i915@pci:0000:00:02.0 11,1% ( 21,6) <interrupt> : uhci_hcd:usb3, ipw3945, HDA Intel,ohci1394 4,8% ( 9,4) zen-updater : schedule_timeout (process_timeout) 2,6% ( 5,0) tpb : do_nanosleep (hrtimer_wakeup) 2,5% ( 4,8) X : do_setitimer (it_real_fn) ******************************************************************************** -- ----------------------------------------------------------- | \ /\_/\ | | ~x~ |/-----\ / \ /- \_/ ^^__ _ / _ ____ / <°°__ \- \_/ | |/ | | || || _| _| _| _| if you really want to see the pictures above - use some font with constant spacing like courier! :-) ----------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-mobile+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mobile+help@opensuse.org
participants (2)
-
Dieter Jurzitza -
Thomas Renninger