J'ai testé PowerTop pour voir ce que ça donne. Intéressant même si les résultats ne sont pas forcément évidents à interpréter. Pour faire rapide, voila un exemple :
Réveils par seconde depuis l'état de repos : 339,0
Pas d'estimations ACPI de la consommation électrique disponible
Principales causes de réveils :
29,1% (215,4) firefox-bin : schedule_timeout (process_timeout)
27,0% (200,2) xmms : schedule_timeout (process_timeout)
13,5% (100,0) S06cpuspeed : queue_delayed_work_on (delayed_work_timer_fn)
6,9% ( 50,8) : uhci_hcd:usb3, ehci_hcd:usb7
5,0% ( 36,8) Xorg : do_setitimer (it_real_fn)
3,9% ( 29,2) mlnet : schedule_timeout (process_timeout)
2,9% ( 21,2) xchat : schedule_timeout (process_timeout)
1,9% ( 14,2) mixer_applet2 : schedule_timeout (process_timeout)
1,7% ( 12,8) gnome-terminal : schedule_timeout (process_timeout)
1,3% ( 10,0) mono : schedule_timeout (process_timeout)
1,3% ( 10,0) thunderbird-bin : schedule_timeout (process_timeout)
1,0% ( 7,6) : uhci_hcd:usb4, libata, libata, eth0
0,5% ( 4,0) <kernel module> : usb_hcd_poll_rh_status (rh_timer_func)
0,5% ( 3,6) : ide0, uhci_hcd:usb2Je ne sais pas si c'est normal de ne pas avoir une "estimations ACPI de la consommation électrique". Sachant que j'ai un core 2 duo... option de compile du kernel ?
On peut voir dans mon exemple (PC au repos avec firefox sur quelques sites + xmms lancé mais qui ne fait rien) que l'on a sur le podium firefox, xmms et cpuspeed ...
Pour firefox, ça ne me choque pas particulièrement, le flash et tout ça, c'est vite couteux.
Par contre, pour xmms, au repos, consommer autant que firefox ... peut on en conclure que xmms abuse des ressources ???
Pour cpuspeed, c'est un peu surprenant aussi ... bref.
Je trouve aussi le comportement de la première ligne très surprenant ("Réveils par seconde depuis l'état de repos") : commence a 339,0 puis on se retrouve avec 2 virgules 339,5,0 puis on part sur des chiffres du genre 32856,6 ... un peu déroutant, problème de rafraichissement de l'affichage ?
On peut noter qu'il est plus intéressant de le faire tourner sur d'autres CPU pour avoir plus d'info :
Les informations détaillées sur les C-states ne sont disponibles qu'avec des CPU mobiles (pour ordinateurs portables)
Voila ... certains d'entre vous ont testé ce logiciel ? Un petit retour serait intéressant.
# Test
Posté par seeschloss . Évalué à 1.
Cn Avg residency (5s) Long term residency avg
C0 (cpu running) (24.0%)
C1 0.0ms ( 0.0%) 0.0ms
C2 0.7ms (76.0%) 0.8ms
C3 0.0ms ( 0.0%) 0.0ms
No detailed statistics available; please enable the CONFIG_TIMER_STATS kernel option
This option is located in the Kernel Debugging section of menuconfig
(which is CONFIG_DEBUG_KERNEL=y in the config file)
Suggestion: Enable the CONFIG_USB_SUSPEND kernel configuration option.
This option will automatically disable UHCI USB when not in use, and may
save approximately 1 Watt of power
Alors je vais me recompiler un kernel comme il faut... merci de m'avoir fait découvrir ce logiciel, cependant _o/
[^] # Re: Test
Posté par guitouu . Évalué à 3.
[^] # Re: Test
Posté par Smarter . Évalué à 5.
# Patch
Posté par jiyuu . Évalué à 6.
on trouve differents patchs pour certaines applications telles que:
Xorg, Firefox, Evolution, Pidgin/GAIM, le kernel...
Il manque plus qu'une facon rapide de connaitre sa consommation electrique et l'on pourra jouer a qui a la plus grosse consomme le moins. :)
[^] # Re: Patch
Posté par med . Évalué à 2.
Chez moi cat /proc/acpi/battery/BAT0/state me donne la consommation quand je suis sur batterie. Mon portable consomme typiquement entre 11 et 13 W quand je suis sur batterie avec le wifi allumé. Pour information j'ai un asus A3N.
[^] # Re: Patch
Posté par guitouu . Évalué à 3.
Je laisse le soin aux développeurs de ces applications d'appliquer ces patchs rapidement... je ne vais pas faire ma petite cuisine de mon coté, ça n'a pas beaucoup d'intérêt.
Par contre, en regardant les résultats que j'obtiens, si on considère que Firefox sur-consomme, je pense qu'on peut dire que XMMS aussi ...
# macbook
Posté par thranduil . Évalué à 4.
Cn Avg residency (5s) Long term residency avg
C0 (cpu running) ( 7.6%)
C1 0.0ms ( 0.0%) 0.0ms
C2 1.9ms (18.4%) 1.8ms
C3 1.8ms (74.0%) 1.8ms
Wakeups-from-idle per second : 992.4
Power usage (ACPI estimate) : 20.4 W (2.1 hours left)
Top causes for wakeups:
40.3% (197.6) <interrupt> : uhci_hcd:usb1, ehci_hcd:usb5
14.4% (70.6) <interrupt> : uhci_hcd:usb4, eth0, i915@pci:0000:00:02.0
12.0% (59.0) firefox-bin : do_futex (hrtimer_wakeup)
9.5% (46.8) <interrupt> : HDA Intel
7.8% (38.2) amarokapp : schedule_timeout (process_timeout)
2.7% (13.2) <interrupt> : libata
2.0% (10.0) cpufreq-set : cpufreq_governor_dbs (delayed_work_timer_f
2.0% ( 9.8) qjackctl : schedule_timeout (process_timeout)
1.6% ( 8.0) modprobe : usb_hcd_poll_rh_status (rh_timer_func)
1.4% ( 7.0) compiz.real : schedule_timeout (process_timeout)
Suggestion: Enable the CONFIG_SND_AC97_POWER_SAVE kernel configuration option.
This option will automatically power down your sound codec when not in use,
and can save approximately half a Watt of power.
En gros la gestion de l'usb plombe tout, en sachant que le clavier et le touchpad sont dessus.
[1] conf et package dispos sur http://nicolas.degory.free.fr/blog/index.php/2007/04/10/21-realtime-linux-sur-un-macbook
[^] # Re: macbook
Posté par med . Évalué à 4.
[^] # Re: macbook
Posté par thranduil . Évalué à 7.
USB1 = touchpad, clavier, controleur usb uhci
USB2 = controleur usb uhci
USB3 = controleur usb uhci, IR
USB4 = controleur usb uhci, carte wifi
USB5 = controleur usb ehci
Avant le patch :
<interrupt> : uhci_hcd:usb1, ehci_hcd:usb5
<interrupt> : uhci_hcd:usb4, eth0, i915@pci:0000:00:02.0
causent chacun entre 70 et 200 réveils par seconde.
Après le patch :
<interrupt> : uhci_hcd:usb4, eth0, i915@pci:0000:00:02.0
cause en moyenne 50 réveils par seconde, l'autre ligne a disparu.
Après le patch le touchpad et le clavier deviennent négligeables pour powertop, il reste en gros le pilote wifi (ndiswrapper en attendant que madwifi soit stabilisé), et le pilote du chipset graphique intel.
La consommation tombe autour des 17W, un gain eventuel de 3W quand même !
Merci pour le lien.
[^] # Re: macbook
Posté par herodiade . Évalué à 4.
interrupt : uhci_hcd:usb4, eth0, i915@pci:0000:00:02.0
cause en moyenne 50 réveils par seconde, l'autre ligne a disparu. »
As tu essayé en désactivant la 3D (fut-ce provisoirement, simplement pour vérifier la cause du problème) ? Pour cela il suffit de mettre « Option "NoDRI" » dans la section Device correspondant à la carte graphique (bon, et du coup, désactiver temporairement ton compiz, aussi).
Il y a un bug connu, qui affecte les drivers i915, ati, radeon et fglrx et qui cause une interruption par rafraichissement si le DRI est activé (donc si ton affichage est à 50Hz, ça fait 50 interuptions/seconde), et ce même lorsqu'on n'est pas en train de faire du rendu 3D (autrement dit : il suffit d'avoir le DRI actif pour que le bug se manifeste). Intel travaille sur le problème pour son chipset (je crois que c'est déjà patché dans xorg & le kernel de développement).
Aussi, sur la même IRQ : passe ton wifi en mode « économie d'énergie » :
iwpriv eth0 set_power 5
(+ si tu peut régler ton AP, réduire la fréquence d'envoi des beacons à 1 par seconde, par exemple).
Concernant le reste de tes "Top causes for wakeups:" :
* "interrupt : HDA Intel ", "interrupt : libata", "modprobe : usb_hcd_poll_rh_status" : ceux là sont très probablement causés par HAL (re-lance PowerTOP après avoir tué hald, pour vérifier).
* "(59.0) firefox-bin" : connu, bug reporté, un patch existe
* "Enable the CONFIG_SND_AC97_POWER_SAVE kernel configuration option" : bin oui, juste fait-le ;)
* "( 9.8) qjackctl : schedule_timeout " : là on a visiblement un beau bug. Ce programme est-il résident pendant longtemps en mémoire ? ta config de Jack n'est-elle pas trop tordue ? Ça mérite inspection (strace et bug report).
Cela dit : "C3 1.8ms (74.0%) 1.8ms" : ce n'est déjà pas trop mal, on a vu pire (mais vu les remarques plus haut, il y a quand même de la marge pour améliorer tout ça :).
[^] # Re: macbook
Posté par thranduil . Évalué à 1.
Réveils par seconde depuis l'état de repos : 2759,7
Consommation électrique (estimation ACPI) : 20,9 W (2,2 heures restantes)
Principales causes de réveils :
96,7% (3515,0) <interrupt> : wlan0
1,6% ( 58,4) firefox-bin : do_futex (hrtimer_wakeup)
0,3% ( 10,0) cpufreq-set : cpufreq_governor_dbs (delayed_work_timer_fn)
0,3% ( 10,0) <kernel module> : wrap_set_timer (timer_proc)
0,2% ( 8,0) <kernel module> : usb_hcd_poll_rh_status (rh_timer_func)
0,2% ( 6,2) <interrupt> : uhci_hcd:usb2, libata
Il reste le wifi (ndiswrapper, pas mal hein ! le pilote madwifi fait un peu mieux) et firefox (je vais attendre que la correction soit dans le package de debian).
pour le reste c'est du noyau.
[^] # Re: macbook
Posté par herodiade . Évalué à 2.
Ah oui, 3515 wps, c'est dément !
On a un nouvel argument libriste : « ndiswrapper saimal, ça détruit la planète » ;).
( 10,0) cpufreq-set : cpufreq_governor_dbs (delayed_work_timer_fn)
Un logiciel userland qui sélectionne le « governor » CPU et qui bouffe lui-même plein d'énergie ? Tu peut le désinstaller je pense.
D'autant plus qu'Arjan est formel sur ce point : il n'y a aucune ambiguité, le governor le plus adapté pour les environnements Intel (donc y compris les macbooks), c'est « ondemand ». Les autres sont moins efficaces. Pour l'activer, fait ceci pour chaque CPU :
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
pour le reste c'est du noyau.
Oui mais c'est bien souvent le userland qui conduit le noyau à recevoir des interruptions USB et ATA (note : outre les réveils de la CPU, le fait de maintenir une activité sur ces bus les empêchent d'activer leurs propres modes d'économie d'énergie indépendants, tels que USB_SUSPEND, dont ils sont tout deux dotés).
Comme je disait plus haut, dans ton cas (usb_hcd_poll_rh_status et libata), je soupçonne "hald". Est-ce que ces lignes disparaissent si tu killall hald ?
De plus, toujours pour réduire les accès disques ou leur impact, tu peut activer le mode laptop si ce n'est pas déjà fait ( echo 5 > /proc/sys/vm/laptop_mode) et monter les partitions pour lesquelles tu ne t'intéresse pas au dates de dernier accès aux fichiers en "noatime". Bon, pour l'USB, il y a aussi un problème connu affectant les macbooks, qui fait que la gestion du clavier est très gourmande (mais un patch existe, peut-être même déjà intégré dans 2.6.22-rc3).
Combien de réveils par secondes et de Watt consommés si tu décharge le module wifi et applique ces astuces ? (ça m'intéresse beaucoup parce que j'envisage de me procurer un macbook aussi :).
[^] # Re: macbook
Posté par thranduil . Évalué à 1.
mon noyau n'étant pas encore patché. Je n'ai alors plus de ligne concernant le governor.
En déchargeant le wifi je n'obtiens qu'au plus 1 W d'économie.
Je ne vois aucune différence en tuant hald.
En comparaison, une diminution de l'intensité de l'écran (qui fait du bien aux yeux en environnement sombre) fait gagner 5W !
[^] # Re: macbook
Posté par herodiade . Évalué à 2.
Oui, le rétro-éclairage (backlight) et la luminosité (brightness, ps: je ne suis pas sûr que ce soit les traductions standards pour ces deux mots) sont parmi les plus gros consommateurs d'énergie sur les portables. Pavel Macek (développeur noyau chez SuSE) dit même « le plus gros consommateur » dans son étude [http://atrey.karlin.mff.cuni.cz/~pavel/swsusp/8hours.pdf].
Cela étant, ces deux aspects (backlight et brightness) sont censés être connus et automatiquement et adéquatement ajustés par le daemon acpi (et ses scripts de configuration /etc/acpi/*) selon que l'ordinateur est branché sur secteur ou pas, sur les distributions modernes. Et on est censé pouvoir lui faire confiance pour gérer ça au mieux. Si acpid ne fait pas ce travail de façon optimale sur ton ordinateur, ça mérite un rapport de bug.
Mais il est pertinent de rappeler que l'écran joue pour beaucoup sur la consommation électrique : ainsi ceux pour qui l'autonomie est un critère prioritaire devraient privilégier les ordinateurs avec de petits écrans (un exemple : Keith Packard obtient 7h d'autonomie sur son Panasonic R4 avec un écran 10 pouces).
# ...
Posté par M . Évalué à 5.
J'en deduis que tu es sur un desktop, et donc tu n'es pas sur batterie (d'ou le "estimations ACPI de la consommation électrique").
De plus le cpuspeed doit te proposer des fréquences CPU alternatives ridicules.
Enfin powertop ne te sert à rien (sauf si tu veux regarder quelles appli consoment trop en vue de ne pas les utiliser sur un portable). Powertop n'est utile qu'avec les C-state.
[^] # Re: ...
Posté par inico (site web personnel) . Évalué à 9.
Donc powertop est aussi utile pour les desktop et pour les serveurs (mon serveur de fichier passe son temps à idle)
[^] # Re: ...
Posté par M . Évalué à 3.
Ta workstation a des C-state ?
Non, donc même si un process se réveille/endors fréquemment, ca ne changera quasiment rien à ta conso (tu resteras toujours en C-state 0).
Pour passer en C-state 3 ou 4, il faut que le processeur n'ai rien à faire, un réveille le force à passer en C-state 0 et il mettra un certains temps à repasser en C-state 3 ou 4.
Tu auras peut être passé quelques ms/µs de moins en idle, mais je pense pas que ca soit flagrant sur la conso *.
* c'est facile a tester : sur un portable désactiver les C-state, et lancer un process qui fait pas mal de wakeup/sleep. Voir si ca impacte de manière non négligeable la conso.
Ou encore brancher un ampèremètre sur ton PC.
Donc powertop est aussi utile pour les desktop et pour les serveurs (mon serveur de fichier passe son temps à idle)
As une explication (ou un lien) qui étaye ton affirmation ?
[^] # Re: ...
Posté par guitouu . Évalué à 4.
L'impact pour les portables est comme tu viens de le dire évident : à cause des C-states.
Par contre pour les PC fixes, est ce que ca réduit un peu la consommation de la machine ? Pas sur. Ca réduit la charge du processeur ? A priori oui ... c'est tjrs ca, meme si c'est faible, ca fait tjrs quelques wakeup de moins.
Apres, je pense que c'est aussi tres utile pour la qualité du code, de se dire qu'on a pas des programmes qui se reveillent tout le temps sans raison...
Finalement, je suis tout a fait d'accord pour dire que la conso d'energie n'est pas que le probleme des portables ... pour que cela continue d'avancer, il faudra que le matos avance aussi, pas simplement le code (exemple de C-states qui ne sont pas présents sur les PC) ...
[^] # Re: ...
Posté par M . Évalué à 2.
C'est pas qu'il fonctionne pas bien, c'est que ce fonctionnement (pooling) à été choisit pour X raison et que ca marche pas bien sur les portables.
[^] # Re: ...
Posté par bertrand . Évalué à 7.
Tout ce qui augmente l'activité augmente le risque de passer à 2Ghz.
Et quand je suis un certain temps à 2Ghz, le ventilo commence à ronronner.
La chaleur que le ventilo dissipe, c'est un surplus de consommation électrique, et le conso n'est pas gratuit non plus.
Ensuite, je pense pas voir une grande différence sur ma facture EDF.
Si je veux vraiment la faire baisser, faut que j'éteigne l'ordi :)
Par contre, une amélioration généralisée de la consommation des ordi aurait surement un impact sur la consommation mondiale d'électricité.
[^] # Re: ...
Posté par Pierre Carrier . Évalué à 3.
Pour la consommation d'un desktop, par ordre decroissant d'importance, d'apres mes estimations (attention, quelques evidences, et j'ai un peu mixe usage perso/usage en entreprise) :
- Choisir une alimentation avec un bon rendement, un ecran consommant peu (TFT, si possible petit) et utiliser la mise en veille du moniteur, couper ampli/enceinte quand on n'utilise pas le son, le casque n'a presque que des avantages quand on est seul et devant sa machine
- Mettre la machine en veille autant que possible (suspend to ram entre midi et deux, suspend to disk pour la nuit si vous avez des horaires normaux)
- Regler la mise en veille des disques durs (hdparm)
- Utiliser les diverses frequences du ou des processeur(s) (mais il est plus interessant de regarder l'usage du processeur via top que d'utiliser powertop), les dynamic ticks (du 2.6.21) si votre processeur a des C-states (et dans ce cas-la, powertop devient pertinent)
Bien evidemment, eviter les configurations surdimensionnees (une petite EPIA fait bien souvent l'affaire plutot qu'un Athlon 64 pour un serveur personnel, meme si c'est pas donne). Recycler du vieux matos, s'il ne consomme pas trop, a une grosse portee ecologique.
[^] # Re: ...
Posté par herodiade . Évalué à 3.
En fait, ça ne servira pas (ou peu) à améliorer la consommation d'énergie sur son desktop actuel. *MAIS* :
Repérer dès à présent les applications gourmandes dans son environnement logiciel favoris, les stracer, et envoyer des rapports de bugs permettra à termes d'améliorer la consommation d'énergie pour tout ceux qui utilisent ces logiciels sur un portable (y compris l'auteur du journal, s'il envisage ultérieurement d'utiliser un portable).
Donc non, on ne peut pas dire que ça ne sert à rien, en tout cas si on est prét à faire le (petit) travail de finition après avoir lancé powertop : rapporter les bugs. Au fait, sur ce point, si vous avez un doute, le canal IRC #powertop sur irc.oftc.net est très amical et Arjan (ou d'autres) saura vous aider à faire un bon bug report voir à patcher.
# Quelques explications
Posté par herodiade . Évalué à 1.
Soit tu utilise un ordinateur dont l'APCI ne fournit pas cette information (typiquement, un ordinateur non portable), soit ton portable est branché sur le secteur (dans ce cas, débranche l'alim et relance powertop lorsque tu es sur batterie).
* « Je trouve aussi le comportement de la première ligne très surprenant »
Bug normallement corrigé dans le svn.
* 29,1% (215,4) firefox-bin : schedule_timeout (process_timeout)
Il y a un patch pour améliorer le comportement de firefox sur http://www.linuxpowertop.org/known.php . Quand au flash ...
* 27,0% (200,2) xmms : schedule_timeout (process_timeout)
S'il n'est pas en train de lire de la musique, il y a clairement un bug dans xmms (ou un des modules d'extension de xmms que tu utilise). Là ça ressemble à un select() avec un timeout trop court. Peut tu faire un strace -p $(pidof xmms) stp ?
* 3,5% (100,0) S06cpuspeed : queue_delayed_work_on (delayed_work_timer_fn)
Il y a aussi une astuce pour contourner ce problème sur known.php :
cd /sys/devices/system/cpu/cpu0/cpufreq
cat ondemand/sampling_rate_max > ondemand/sampling_rate
(à faire pour chaque CPU).
*
6,9% ( 50,8) : uhci_hcd:usb3, ehci_hcd:usb7
1,0% ( 7,6) : uhci_hcd:usb4, libata, libata, eth0
0,5% ( 3,6) : ide0, uhci_hcd:usb2
0,5% ( 4,0) <kernel module> : usb_hcd_poll_rh_status (rh_timer_func)
Ces quatre là m'évoquent le problème (connu) d'hald qui polle les lecteurs de cdroms et autres périphériques de stockage de masse USB à intervalles réguliers. Essaie de tuer hald pour confirmer. Vérifie aussi que tu a bien CONFIG_USB_SUSPEND dans le noyau et que tu ne fait pas tourner pcscd.
* 1,9% ( 14,2) mixer_applet2 : schedule_timeout (process_timeout)
Problème connu (cf. known.php)
* 1,3% ( 10,0) mono : schedule_timeout (process_timeout)
Beagled ?
* 1,7% ( 12,8) gnome-terminal : schedule_timeout (process_timeout)
Ça n'est pas normal. Même le curseur clignotant ne doit pas produire autant d'interuptions. Aurais tu quelque chose qui défile dans un terminal (un top, un tail, etc. ?).
* 2,9% ( 21,2) xchat : schedule_timeout (process_timeout)
Connu aussi, si je me souvient bien le problème vient d'une/des extensions/plugins. Essaie de désactiver temporairement le support des plugins python/perl/tcl, pour vérifier qu'ils sont bien les coupables.
* 5,0% ( 36,8) Xorg : do_setitimer (it_real_fn)
Peut être n'importe quoi (une autre application, un fond d'écran animé, ...). C'est une limitation : pour le moment PowerTOP ne permet pas de distinguer le travail que Xorg fait de son propre chef et ce qu'il fait à la demande d'un autre logiciel.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.