En ayant un peu marre de voir la facture d'électricité augmenter à
chaque fois que je la reçois, et surtout d'entendre les commentaires de
ma femme aller à l'unison, et ayant dans le même temps des machines qui
ronronnent gentiment sans réellement atteindre des cadences infernales,
j'ai fouillé un peu pour trouver une solution.
La meilleure que j'ai trouvée, c'est powerd. En mode adaptative, ça
semble parfait pour limiter un peu la consommation, mais bon, est-ce
que ça vaut vraiment le coup ?
La meilleure que j'ai trouvée, c'est powerd. En mode adaptative, ça semble parfait pour limiter un peu la consommation, mais bon, est-ce que ça vaut vraiment le coup ?
Il faut que le cpu de ta machine le supporte, sur l'amd64 qui me sert de machine principale, le processeur ne supporte pas de changer de vitesse...
-- Même à 15 minutes par livre à 250°, un con reste un con, et celui là restera pour encore un bon moment un con majuscule. On devrait le mettre à Sèvre, sous cloche, le con étalon. (c)(r)(tm) -+- RM in http://neuneu.ctw.cc - Comment servir le neuneu -+-
Stephane Catteau <steph.nospam@sc4x.net> writes:
'Lut,
La meilleure que j'ai trouvée, c'est powerd. En mode adaptative, ça
semble parfait pour limiter un peu la consommation, mais bon, est-ce
que ça vaut vraiment le coup ?
Il faut que le cpu de ta machine le supporte, sur l'amd64 qui me sert de
machine principale, le processeur ne supporte pas de changer de
vitesse...
--
Même à 15 minutes par livre à 250°, un con reste un con, et celui là
restera pour encore un bon moment un con majuscule.
On devrait le mettre à Sèvre, sous cloche, le con étalon. (c)(r)(tm)
-+- RM in http://neuneu.ctw.cc - Comment servir le neuneu -+-
La meilleure que j'ai trouvée, c'est powerd. En mode adaptative, ça semble parfait pour limiter un peu la consommation, mais bon, est-ce que ça vaut vraiment le coup ?
Il faut que le cpu de ta machine le supporte, sur l'amd64 qui me sert de machine principale, le processeur ne supporte pas de changer de vitesse...
-- Même à 15 minutes par livre à 250°, un con reste un con, et celui là restera pour encore un bon moment un con majuscule. On devrait le mettre à Sèvre, sous cloche, le con étalon. (c)(r)(tm) -+- RM in http://neuneu.ctw.cc - Comment servir le neuneu -+-
Eric Masson
Patrick Lamaizière writes:
'Lut,
Peut-on se fier à ça ?: sysctl: dev.cpu.0.freq_levels: 731/-1 685/-1 639/-1 593/-1 548/-1 502/-1 456/-1 411/-1 365/-1 319/-1 274/-1 228/-1 182/-1 137/-1 91/-1 45/-1 dev.acpi_throttle.0.%parent: cpu0 dev.cpufreq.0.%driver: cpufreq
C'est effectivement ce que Free renvoie (à peut de choses près) lorsqu'il peut contrôler la vitesse du proc.
acpi_throttle0: <ACPI CPU Throttling> on cpu0
Cette ligne du dmesg est elle aussi nécessaire.
À titre d'exemple, la sortie de sysctl -a | grep '^dev.cpu' sur l'amd64 qui ne supporte pas le changement de fréquence : dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1800 dev.cpu.0.freq_levels: 1800/89000 1800/89000 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0
Les rares messages que j'ai trouvé sur le sujet font état de l'absence d'un driver powernow dans le framework cpufreq, il faudrait que je boote un linux récent sur cette bécane pour en avoir le coeur net.
-- L'énervement ressentie à te lire étant de loin supérieur aux informations qui pourraient se glisser dans tes contributions, je t'enkille. -+- JP in: Guide du Neuneu Usenet - Neuneu se fait mettre à sec -+-
Patrick Lamaizière <adresse@est.invalid> writes:
'Lut,
Peut-on se fier à ça ?:
sysctl:
dev.cpu.0.freq_levels: 731/-1 685/-1 639/-1 593/-1 548/-1 502/-1 456/-1
411/-1 365/-1 319/-1 274/-1 228/-1 182/-1 137/-1 91/-1 45/-1
dev.acpi_throttle.0.%parent: cpu0
dev.cpufreq.0.%driver: cpufreq
C'est effectivement ce que Free renvoie (à peut de choses près)
lorsqu'il peut contrôler la vitesse du proc.
acpi_throttle0: <ACPI CPU Throttling> on cpu0
Cette ligne du dmesg est elle aussi nécessaire.
À titre d'exemple, la sortie de sysctl -a | grep '^dev.cpu' sur l'amd64
qui ne supporte pas le changement de fréquence :
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 1800
dev.cpu.0.freq_levels: 1800/89000 1800/89000
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
Les rares messages que j'ai trouvé sur le sujet font état de l'absence
d'un driver powernow dans le framework cpufreq, il faudrait que je boote
un linux récent sur cette bécane pour en avoir le coeur net.
--
L'énervement ressentie à te lire étant de loin supérieur aux
informations qui pourraient se glisser dans tes contributions, je
t'enkille.
-+- JP in: Guide du Neuneu Usenet - Neuneu se fait mettre à sec -+-
Peut-on se fier à ça ?: sysctl: dev.cpu.0.freq_levels: 731/-1 685/-1 639/-1 593/-1 548/-1 502/-1 456/-1 411/-1 365/-1 319/-1 274/-1 228/-1 182/-1 137/-1 91/-1 45/-1 dev.acpi_throttle.0.%parent: cpu0 dev.cpufreq.0.%driver: cpufreq
C'est effectivement ce que Free renvoie (à peut de choses près) lorsqu'il peut contrôler la vitesse du proc.
acpi_throttle0: <ACPI CPU Throttling> on cpu0
Cette ligne du dmesg est elle aussi nécessaire.
À titre d'exemple, la sortie de sysctl -a | grep '^dev.cpu' sur l'amd64 qui ne supporte pas le changement de fréquence : dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1800 dev.cpu.0.freq_levels: 1800/89000 1800/89000 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0
Les rares messages que j'ai trouvé sur le sujet font état de l'absence d'un driver powernow dans le framework cpufreq, il faudrait que je boote un linux récent sur cette bécane pour en avoir le coeur net.
-- L'énervement ressentie à te lire étant de loin supérieur aux informations qui pourraient se glisser dans tes contributions, je t'enkille. -+- JP in: Guide du Neuneu Usenet - Neuneu se fait mettre à sec -+-
patpro ~ patrick proniewski
Bonjour,
Je profite du thread pour poser mes propres questions sur le sujet :
De mon coté, c'est une machine à base de bi-xeon LV dual core (sossaman), dont la caractéristique première des cpu est une enveloppe thermique de seulement 31W. Ces proc sont assez modernes et sont supposés supporter des fonctions d'économie d'énergie.
CPU: Intel(R) Xeon(TM) CPU 000 @ 1.66GHz (1666.79-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6e8 Stepping = 8 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP, MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2, SS,HTT,TM,PBE> Features2=0xc1a9<SSE3,MON,VMX,EST,TM2,<b14>,<b15>> AMD Features=0x100000<NX> Cores per package: 2
Je ne connais rien à la gestion d'énergie et j'ai besoin de quelques éclaircissements. Après un passage dans sysctl, voilà ce que j'ai :
J'ai trouvé C1 dans le man acpi, ainsi que le sens des hw.acpi.cpu.* De la même manière j'ai compris suffisamment les dev.cpu.*
Je comprends que dev.cpu.0.freq_levels liste les paliers de fréquences utilisables par le CPU, mais que signifie le /-1 ?
Ais-je besoin de charger explicitement cpufreq.ko, ou est ce que acpi.ko qui est déjà chargé est suffisant ?
Surtout, comment connaître l'état de mes CPU (fréquence effective par exemple) si j'utilise powerd ?
patpro
-- http://www.patpro.net/
Bonjour,
Je profite du thread pour poser mes propres questions sur le sujet :
De mon coté, c'est une machine à base de bi-xeon LV dual core
(sossaman), dont la caractéristique première des cpu est une enveloppe
thermique de seulement 31W.
Ces proc sont assez modernes et sont supposés supporter des fonctions
d'économie d'énergie.
CPU: Intel(R) Xeon(TM) CPU 000 @ 1.66GHz (1666.79-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x6e8 Stepping = 8
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,
MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,
SS,HTT,TM,PBE>
Features2=0xc1a9<SSE3,MON,VMX,EST,TM2,<b14>,<b15>>
AMD Features=0x100000<NX>
Cores per package: 2
Je ne connais rien à la gestion d'énergie et j'ai besoin de quelques
éclaircissements.
Après un passage dans sysctl, voilà ce que j'ai :
Je profite du thread pour poser mes propres questions sur le sujet :
De mon coté, c'est une machine à base de bi-xeon LV dual core (sossaman), dont la caractéristique première des cpu est une enveloppe thermique de seulement 31W. Ces proc sont assez modernes et sont supposés supporter des fonctions d'économie d'énergie.
CPU: Intel(R) Xeon(TM) CPU 000 @ 1.66GHz (1666.79-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6e8 Stepping = 8 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP, MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2, SS,HTT,TM,PBE> Features2=0xc1a9<SSE3,MON,VMX,EST,TM2,<b14>,<b15>> AMD Features=0x100000<NX> Cores per package: 2
Je ne connais rien à la gestion d'énergie et j'ai besoin de quelques éclaircissements. Après un passage dans sysctl, voilà ce que j'ai :
Ais-je besoin de charger explicitement cpufreq.ko, ou est ce que acpi.ko qui est déjà chargé est suffisant ?
powerd marche out-of-the-box
Surtout, comment connaître l'état de mes CPU (fréquence effective par exemple) si j'utilise powerd ?
dev.cpu.0.freq est mis à jour proprement. Je tourne maintenant à 208 MHz
Ho joie. Plus qu'à surveiller la courbe de température interne de la machine pour voir si ça chute ;)
patpro
-- http://www.patpro.net/
Eric Masson
patpro ~ patrick proniewski writes:
'Lut,
Surtout, comment connaître l'état de mes CPU (fréquence effective par exemple) si j'utilise powerd ?
Tu regardes du coté des sysctl donnant la fréquence effective des procs dev.cpu.n.freq
-- Par exemple, un groupe fr.bla.bla est proposé. Les résultats de l'AAV datent du 15-10-99. Le vote est négatif. Une nouvelle proposition ne pourra se faire que six mois plus tard, soit le 15-04-99, n'est-ce pas? -+- BC In GNU - Le bog de l'an 2000 est en avance cette année -+-
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> writes:
'Lut,
Surtout, comment connaître l'état de mes CPU (fréquence effective par
exemple) si j'utilise powerd ?
Tu regardes du coté des sysctl donnant la fréquence effective des procs
dev.cpu.n.freq
--
Par exemple, un groupe fr.bla.bla est proposé. Les résultats de l'AAV
datent du 15-10-99. Le vote est négatif. Une nouvelle proposition ne
pourra se faire que six mois plus tard, soit le 15-04-99, n'est-ce pas?
-+- BC In GNU - Le bog de l'an 2000 est en avance cette année -+-
Surtout, comment connaître l'état de mes CPU (fréquence effective par exemple) si j'utilise powerd ?
Tu regardes du coté des sysctl donnant la fréquence effective des procs dev.cpu.n.freq
-- Par exemple, un groupe fr.bla.bla est proposé. Les résultats de l'AAV datent du 15-10-99. Le vote est négatif. Une nouvelle proposition ne pourra se faire que six mois plus tard, soit le 15-04-99, n'est-ce pas? -+- BC In GNU - Le bog de l'an 2000 est en avance cette année -+-
patpro ~ patrick proniewski
In article , Patrick Lamaizière wrote:
Sinon powerd a un mode verbose '-v' : # powerd -v -a adaptive -p 200 idle time < 65%, increasing clock speed from 45 MHz to 137 MHz idle time > 90%, decreasing clock speed from 137 MHz to 91 MHz idle time > 90%, decreasing clock speed from 91 MHz to 45 MHz
ha oui, sympa ça, pour tester le basar. Merci
patpro
-- http://www.patpro.net/
In article <Xns440915D0BDFB3plam@nulle.invalid>,
Patrick Lamaizière <adresse@est.invalid> wrote:
Sinon powerd a un mode verbose '-v' :
# powerd -v -a adaptive -p 200
idle time < 65%, increasing clock speed from 45 MHz to 137 MHz
idle time > 90%, decreasing clock speed from 137 MHz to 91 MHz
idle time > 90%, decreasing clock speed from 91 MHz to 45 MHz
Sinon powerd a un mode verbose '-v' : # powerd -v -a adaptive -p 200 idle time < 65%, increasing clock speed from 45 MHz to 137 MHz idle time > 90%, decreasing clock speed from 137 MHz to 91 MHz idle time > 90%, decreasing clock speed from 91 MHz to 45 MHz
ha oui, sympa ça, pour tester le basar. Merci
patpro
-- http://www.patpro.net/
patpro ~ patrick proniewski
In article , Eric Masson wrote:
patpro ~ patrick proniewski writes:
'Lut,
Surtout, comment connaître l'état de mes CPU (fréquence effective par exemple) si j'utilise powerd ?
Tu regardes du coté des sysctl donnant la fréquence effective des procs dev.cpu.n.freq
oui, j'ai fini par trouver ça. Je n'étais pas sûr a priori qu'il ne garderait pas la valeur trouvée au boot.
merci,
patpro
-- http://www.patpro.net/
In article <psgp74-gqg.ln1@srvbsdnanssv.oursoides-associes.com>,
Eric Masson <emss@free.fr> wrote:
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> writes:
'Lut,
Surtout, comment connaître l'état de mes CPU (fréquence effective par
exemple) si j'utilise powerd ?
Tu regardes du coté des sysctl donnant la fréquence effective des procs
dev.cpu.n.freq
oui, j'ai fini par trouver ça. Je n'étais pas sûr a priori qu'il ne
garderait pas la valeur trouvée au boot.
dev.cpu.0.freq est mis à jour proprement. Je tourne maintenant à 208 MHz
Ho joie. Plus qu'à surveiller la courbe de température interne de la machine pour voir si ça chute ;)
et bien les températures ne bougent pas... dommage. CPU0 stable à 35,5 °C CPU1 stable à 30 °C Carte mère stable à 33 °C
j'imagine que si ça chauffe autant qu'avant, c'est que ça consomme autant qu'avant.
Eric, tu nous a répondu sur pas mal de points, as-tu un avis sur le chargement de cpufreq.ko ?
patpro
-- http://www.patpro.net/
Cyrille Szymanski
patpro ~ patrick proniewski wrote in news::
Sinon powerd a un mode verbose '-v' : # powerd -v -a adaptive -p 200 idle time < 65%, increasing clock speed from 45 MHz to 137 MHz idle time > 90%, decreasing clock speed from 137 MHz to 91 MHz idle time > 90%, decreasing clock speed from 91 MHz to 45 MHz
ha oui, sympa ça, pour tester le basar. Merci
Malheureusement tous les CPU ne réagissent pas de la même façon, un algo qui fonctionne bien sur l'un aura un résultat catastrophique sur l'autre. C'est là qu'est le problème pour adaptive.
Il se trouve que je me suis beaucoup penché sur la question récemment. En l'état actuel de powerd les utilisateurs mobiles remarquent en général qu'il diminue l'autonomie de leur machine en mode adaptive.
Pourquoi ? Tout le noeud du problème est de trouver le juste milieu entre un temps d'exécution plus long et une fréquence trop élevée. Mais entre aussi en jeu le fait qu'à fréquence fixe, un CPU ne consomme pas autant s'il est idle que s'il est à 100%, et le fait que de plus en plus le matériel implante ses propres modes d'économie d'énergie. En modélisant tout ça, on se rend vite compte à quel point on peut se planter si on fait des erreurs sur les estimations des paramètres. Non seulement le proc consommera plus, mais la machine sera plus lente.
Donc la recommendation à laquelle j'en suis arrivé est de fixer à la main la vitesse du proc en fonction de l'utilisation qui en est faite. On peut imaginer un crontab qui fasse ça, maxi en journée et mini la nuit devrait donner de bons résultats. Mais encore plus ici qu'ailleurs, YMMV.
J'espère quand-même arriver à implémenter des améliorations à powerd. Vos conseils sont donc les bienvenus.
-- Cyrille Szymanski
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote in
news:patpro-1080C9.12592014012007@news-1.proxad.net:
Sinon powerd a un mode verbose '-v' :
# powerd -v -a adaptive -p 200
idle time < 65%, increasing clock speed from 45 MHz to 137 MHz
idle time > 90%, decreasing clock speed from 137 MHz to 91 MHz
idle time > 90%, decreasing clock speed from 91 MHz to 45 MHz
ha oui, sympa ça, pour tester le basar. Merci
Malheureusement tous les CPU ne réagissent pas de la même façon, un algo
qui fonctionne bien sur l'un aura un résultat catastrophique sur l'autre.
C'est là qu'est le problème pour adaptive.
Il se trouve que je me suis beaucoup penché sur la question récemment. En
l'état actuel de powerd les utilisateurs mobiles remarquent en général
qu'il diminue l'autonomie de leur machine en mode adaptive.
Pourquoi ? Tout le noeud du problème est de trouver le juste milieu entre
un temps d'exécution plus long et une fréquence trop élevée. Mais entre
aussi en jeu le fait qu'à fréquence fixe, un CPU ne consomme pas autant
s'il est idle que s'il est à 100%, et le fait que de plus en plus le
matériel implante ses propres modes d'économie d'énergie. En modélisant
tout ça, on se rend vite compte à quel point on peut se planter si on
fait des erreurs sur les estimations des paramètres. Non seulement le
proc consommera plus, mais la machine sera plus lente.
Donc la recommendation à laquelle j'en suis arrivé est de fixer à la main
la vitesse du proc en fonction de l'utilisation qui en est faite. On peut
imaginer un crontab qui fasse ça, maxi en journée et mini la nuit devrait
donner de bons résultats. Mais encore plus ici qu'ailleurs, YMMV.
J'espère quand-même arriver à implémenter des améliorations à powerd. Vos
conseils sont donc les bienvenus.
Sinon powerd a un mode verbose '-v' : # powerd -v -a adaptive -p 200 idle time < 65%, increasing clock speed from 45 MHz to 137 MHz idle time > 90%, decreasing clock speed from 137 MHz to 91 MHz idle time > 90%, decreasing clock speed from 91 MHz to 45 MHz
ha oui, sympa ça, pour tester le basar. Merci
Malheureusement tous les CPU ne réagissent pas de la même façon, un algo qui fonctionne bien sur l'un aura un résultat catastrophique sur l'autre. C'est là qu'est le problème pour adaptive.
Il se trouve que je me suis beaucoup penché sur la question récemment. En l'état actuel de powerd les utilisateurs mobiles remarquent en général qu'il diminue l'autonomie de leur machine en mode adaptive.
Pourquoi ? Tout le noeud du problème est de trouver le juste milieu entre un temps d'exécution plus long et une fréquence trop élevée. Mais entre aussi en jeu le fait qu'à fréquence fixe, un CPU ne consomme pas autant s'il est idle que s'il est à 100%, et le fait que de plus en plus le matériel implante ses propres modes d'économie d'énergie. En modélisant tout ça, on se rend vite compte à quel point on peut se planter si on fait des erreurs sur les estimations des paramètres. Non seulement le proc consommera plus, mais la machine sera plus lente.
Donc la recommendation à laquelle j'en suis arrivé est de fixer à la main la vitesse du proc en fonction de l'utilisation qui en est faite. On peut imaginer un crontab qui fasse ça, maxi en journée et mini la nuit devrait donner de bons résultats. Mais encore plus ici qu'ailleurs, YMMV.
J'espère quand-même arriver à implémenter des améliorations à powerd. Vos conseils sont donc les bienvenus.
-- Cyrille Szymanski
Stephane Catteau
Eric Masson n'était pas loin de dire :
La meilleure que j'ai trouvée, c'est powerd. En mode adaptative, ça semble parfait pour limiter un peu la consommation, mais bon, est-ce que ça vaut vraiment le coup ?
Il faut que le cpu de ta machine le supporte, sur l'amd64 qui me sert de machine principale, le processeur ne supporte pas de changer de vitesse...
En théorie ils devraient tous supporter ça.
Eric Masson n'était pas loin de dire :
La meilleure que j'ai trouvée, c'est powerd. En mode adaptative, ça
semble parfait pour limiter un peu la consommation, mais bon, est-ce
que ça vaut vraiment le coup ?
Il faut que le cpu de ta machine le supporte, sur l'amd64 qui me sert de
machine principale, le processeur ne supporte pas de changer de
vitesse...
La meilleure que j'ai trouvée, c'est powerd. En mode adaptative, ça semble parfait pour limiter un peu la consommation, mais bon, est-ce que ça vaut vraiment le coup ?
Il faut que le cpu de ta machine le supporte, sur l'amd64 qui me sert de machine principale, le processeur ne supporte pas de changer de vitesse...
