Lors de l'IDF 2007, vitrine technologique d'intel, ce dernier nous dévoile un site http://LessWatts.org/ vissant à réunir des petites astuces et grandes documentations pour économiser quelques watts par-ci par-là sur votre portable et, tout cela, sous linux. Ce site est surtout tourné pour les portables équipés tout intel mais les conseils peuvent très bien être utilisés sur d'autre platforme comme AMD ou des PC ou serveur lorsqu'ils ne demandent pas de materiel spécifique.
Perso, les commandes sympas y sont expliqués. On ne vous balance pas une commande sans dire le pourquoi du comment. Le site en lui-même n'est pas bourré de "INTEL" dans tout les sens. D'ailleurs, s'il n'y avait pas la bannière, on ne saurait pas que c'est une initiative d'intel.
Sinon, encore un webmaster qui ne connaît pas "body { background-color: white };"
source: http://www.pcinpact.com/actu/news/39034-Intel-LessWattsorg-e(...)
NB: Je n'ai rien contre EDF.
Journal Intel contre EDF.
21
sept.
2007
# Linux ?
Posté par Aldoo . Évalué à 10.
Enfin, je dis ça, je dis rien, mais sous konqueror, j'ai du mal...
Or puisqu'il s'agit d'économiser de précieux wattheures, je ne vais évidemment pas lancer Firefox !
[^] # Re: Linux ?
Posté par Obsidian . Évalué à 2.
[^] # Re: Linux ?
Posté par Aldoo . Évalué à 3.
[^] # Re: Linux ?
Posté par KiKouN . Évalué à 3.
[^] # Re: Linux ?
Posté par Aldoo . Évalué à 2.
J'ai la zone de titre et le menu, ainsi que le pied de page, mais il manque l'essentiel.
[^] # Re: Linux ?
Posté par 태 (site web personnel) . Évalué à 3.
[^] # Re: Linux ?
Posté par KiKouN . Évalué à 1.
Résultat: J'ai un site avec un fond gris très peu lisible (noir sur gris, c'est pas le top) et de belles images avec des zones blanches sur les bords qui font tâches là où elles devraient donner un superbe aspect arrondi à l'image.
[^] # Re: Linux ?
Posté par 태 (site web personnel) . Évalué à 6.
Si tu trouves que les couleurs par défaut de ton navigateur ne sont pas assez lisibles, change-les !
[^] # Re: Linux ?
Posté par Alex . Évalué à 2.
[^] # Re: Linux ?
Posté par Aldoo . Évalué à 2.
# ???
Posté par Snarky . Évalué à 3.
Pour ça ? Il devrai plutôt connaître "body { background-color: black };", parce que une page blanche consomme plus de courant que une page noir.
Pour un site qui parle d'économie d'énergie... A revoir ^^
[^] # Re: ???
Posté par Thomas Poindessous . Évalué à 4.
contre argument :
http://googleblog.blogspot.com/2007/08/is-black-new-green.ht(...)
[^] # Re: ???
Posté par z a . Évalué à 6.
[^] # Re: ???
Posté par Prosper . Évalué à 7.
# Gains très faibles
Posté par ʭ ☯ . Évalué à 1.
Pour info, j'ai mis ça dans /etc/acpi/actions/lm_ac_adapter.sh (ça doit changer suivants les distributions?) L'essayez pas sans affiner, à moins d'avoir une ATI Radeon X600 ;-)
# this indicates whether the AC was plugged or unplugged
if [ "$4" = "00000001" ]; then
# Cdrom Polling by HAL
hal-disable-polling --device /dev/sr0 --enable-polling
# Hem, HAL crashes here
service haldaemon start 2> /dev/null
# Codec audio no Powersave
echo 0 > /sys/module/snd_ac97_codec/parameters/power_save
echo 1 > /dev/dsp
# radeon graphic card at normal speed
rovclock -c 400 -m 250
else
# No Cdrom Polling by HAL
hal-disable-polling --device /dev/sr0
# Codec audio Powersave enabled
echo 1 > /sys/module/snd_ac97_codec/parameters/power_save
echo 1 > /dev/dsp
# radeon graphic card slowed down
rovclock -c 100 -m 125
fi
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Gains très faibles
Posté par jeffcom . Évalué à 10.
[^] # Re: Gains très faibles
Posté par herodiade . Évalué à 10.
Bref, pour vraiment juger de leur efficacité, il faudrait comparer la consommation d'énergie entre un kernel 2.6.20 (et xorg 7.2.0) et un kernel 2.6.23-rc7 (et xorg 7.3), sur x86.
Sinon, à combien de Watt est-tu, en situation "optimisée" ? Et quelle version du noyau utilise-tu ? Sur quelle architecture ?
La plupart des conseils (au moins, ceux qui visent à réduire les réveils de la CPU) ne sont réellement pertinents qu'avec un noyau tickless (donc >= 2.6.21 et x86, le ticklesss n'étant pas encore supporté par le kernel vanilla sur x86_64 ou ppc). Avec un noyau antérieur ou non x86, c'est beaucoup moins pertinent (pour le moment).
D'autre part lesswatt.org est censé, sou peu, recevoir toutes les astuces indiquées sur http://www.linuxpowertop.org/ , mais le transfert n'est pas encore fini à cette heure.
Et pour finir, il est bien utile de compléter l'application de ces astuces par une recherche des applications gourmandes, avec powertop (parce que les gens d'Intel n'utilisent pas forcément les mêmes logiciels que toi, ou la même version de ces logiciels, ils n'ont peut-être pas noté les bugs de certaines applications que tu utilise).
> hal-disable-polling --device /dev/sr0
Éventuellement faire de même avec les lecteurs smartcard et consorts.
> echo 1 > /sys/module/snd_ac97_codec/parameters/power_save
Note que ceci n'est effectif qu'à condition que les entrées son (micro, line in) soient coupées. Il faudrait peut-être ajouter un coups de "alsactl" ou autre ici. Dans mes scripts j'ai mis :
amixer set Line mute nocap
amixer set Mic mute nocap
> echo 1 > /dev/dsp
Pourquoi faire ?
> rovclock -c 100 -m 125
Alternativement, il y a une autre méthode pour économiser l'énergie avec les radeons (incompatible avec celle-ci) - mais je ne sais pas si elle est plus efficace ou pas (il faut comparer, en ce qui me concerne mon portable est tout Intel ;) : placer 'Option "DynamicClocks" "on"' dans son xorg.conf, et "aticonfig --list-powerstates" et "aticonfig --set-powerstate=1 --effective=now".
Aussi, le DRI et les sucreries 3D (compiz...) causent de très nombreux réveils. Un bon 'Option "NoDRI"' dans xorg suffit à calmer le jeux. Pour finir avec les cartes graphiques : Arjan indique aussi économiser 1 Watt en fermant la sortie TV de sa carte vidéo (Intel) avec un "xrandr --output TV -off", que le driver laisse malencontreusement ouvert. Je ne sait pas ce qu'il en est pour les radeons, mais ça vaut la peine d'enquêter...
Quelques pistes pouvant aider à compléter ton script (ou pas) :
# désactiver le Wake-On-Lan
ethtool -s eth0 wol d
# activer le laptop mode
echo 5 > /proc/sys/vm/laptop_mode
# si son système est stable, pas la peine de causer de nombreux
# réveils CPU avec la surveillance des "Non Maskable Interrupt".
echo 0 > /proc/sys/kernel/nmi_watchdog
# rendre l'ordonanceur CPU plus économe (nb le nom
# de ce fichier peut varier selon les phases lunaires,
# par ex. sched_smt_power_savings).
echo 1 > /sys/devices/system/cpu/sched_mc_power_savings
# tuer les divers daemons de gestion de la vitesse CPU
# (cpufreqd, cpudyn & co) et choisir un algo efficace et adapté
# aux kernels tickless :
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# ceci n'est utile que si le kernel est antérieur au 2.6.22
cd /sys/devices/system/cpu/cpu0/cpufreq
cat ondemand/sampling_rate_max > ondemand/sampling_rate
# ça, uniquement si on a appliqué les patchs de gestion d'énergie
# SATA AHCI de Kristen
echo min_power > /sys/class/scsi_host/host0/link_power_management_policy
echo min_power > /sys/class/scsi_host/host1/link_power_management_policy
# réduire la fréquence d'écriture des dirty pages sur le disque
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs
# ça devrait déjà être actif, mais au cas où (ce serait balot de ne
# pas l'avoir activé, ou de ne pas se rendre compte que ça ne
# marche pas !).
xset +dpms
# fermer la sortie tv (avec les drivers xrandrisés, hein)
xrandr --output TV -off
# je sait pas vous, mais je n'ai pas franchement l'utilité de faire
# tourner le bluetooth en permanence, hors ça consomme pas mal
# de jus (autant l'activer manuellement lorsque besoin). Virons-le :
hciconfig hci0 down ; rmmod hci_usb
# À la différence de l'USB2 (qui peut couper l'alimentation du bus
# s'il n'y a pas d'activité), , l'USB1 n'a pas de fonctionnalité
# d'économie d'énergie. Le virer si on n'en n'a pas réellement besoin
# (les périphériques modernes tendent à être usb-2 de tt façons).
# Perso je fait carrément
# "echo "blacklist uhci_hcd" >> /etc/modprobe.d/blacklist"
# et je charge l'usb-1 à la main lorsque (c'est rare) j'en ai besoin.
rmmod uhci_hcd
# Le wifi est très gourmand. Si on a une interface wifi et qu'on
# l'utilise, activer le mode économe :
iwpriv eth1 set_power 5
# et si on ne l'utilise pas, la couper complètement :
# for i in /sys/bus/pci/drivers/*/*/rf_kill; do echo 1> $i ; done
# Si le laptop mode ne l'a pas déjà fait, activer l'économie d'énergie
# pour chaque disque dur :
hdparm -B 1 -S 12 /dev/sda
# la mise à jour du champ "atime" des inodes est passablement
# inutile (cf. les débats récents à ce sujet sur LKML), et cause des
# rotations disques régulières pour updater les inodes (le cache
# disque, utilisé en lecture, permet pourtant souvent de tenir un
# moment sans avoir besoin d'accéder physiquement aux disques),
# bref, faire qq chose comme ça pour toutes les partitions (voir,
# placer ça une fois pour toutes dans son /etc/fstab) :
mount -o remount,noatime /
# penser à désactiver tout les services inutiles. Par exemple :
# utilisez vous réellement l'imprimante, lorsque votre portable
# est sur batterie ?
/etc/init.d/bluetooth stop
/etc/init.d/cupsys stop
/etc/init.d/hplip stop
etc.
Et il y a les conseils pas trop scriptables, indiqués sur lesswatts ou linuxpowertop, comme :
- au lieu de paramétrer un écran de veille, choisir une shutdown complet de l'écran (d'où le dpms plus haut), avec par ex un "xset dpms force standby"
- virer les cochonneries d'indexeurs de fichiers (au moins tant qu'on tourne sur batterie) : beagle & co., et les autres trucs très gourmands (network-manager, compiz, xmms, mixer_applet2, ...)
- régler le rétro-éclairage au minimum lorsqu'on est sur batterie. Après la CPU lorsqu'elle est en pleine activité (et avant le Wifi), l'écran est ce qui consomme le plus d'énergie sur un portable moderne. Il faut chercher le meilleur compromis entre lisibilité et autonomie.
- vérifier dans son BIOS qu'il n'y a pas une option qui masque ou désactive les c-states C3 ou C4 et/ou l'HPET (c'est courant, à cause de limitations de Windows...).
Et vous pouvez aussi aider (et gagner encore de l'énergie) en testant ces patchs (qui devraient aller dans le 2.6.24 si j'ai bien compris, en tout cas le patch -hrt est bien stables chez moi) :
- Activation des hrtimers sur x86_64, activation d'HPET de force sur les chipsets connus pour supporter ce timer (même si le BIOS prétant qu'HPET n'est pas supporté pour ne pas brusquer WinXP) (par Thomas Gleixner) :
http://www.tglx.de/projects/hrtimers/
- SATA AHCI Linux power management (par Kristen Accardi, d'Intel) :
http://www.kernel.org/pub/linux/kernel/people/kristen/patche(...)
Et puis, c'est profitable à tout le monde, repérer les applications qui ne dorment pas lorsqu'elles le devraient (ou qui causent des accès disques, au bus USB, etc.), et reporter des bugs, avec des choses simples comme :
# l'incontournable outil de diagnostic
powertop
# mais strace suffit souvent à repérer les applis déconnantes
strace -p $(pidof tonapp) # pour tt les applis qui tournent
# ceci affiche (dans le dmesg, oui, c'est moche) toutes les applis
# qui causent des accès aux disques :
sysctl vm.block_dump=1
# ceci liste les applis qui ont utilisé bcp de temps CPU
# depuis leur lancement
ps aux | awk '{print$10,$11}' | sort -n
[^] # Re: Gains très faibles
Posté par M . Évalué à 3.
Le virer si on n'en n'a pas réellement besoin
# (les périphériques modernes tendent à être usb-2 de tt façons).
# Perso je fait carrément
Sauf que usb2 ca veut rien dire.
Les periph High speed utilise ehci, les autres (low speed et full speed) uhci.
Ca m'entonnerait que tu arrive a utiliser une souris usb sans uhci (a moins que tu utilise un hub High speed).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.