[FreeBSD] powerd est-il si interessant ?

Stephane Catteau

14/01/2007 à 16:37

Cyrille Szymanski devait dire quelque chose comme ceci :

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%,

Donc si je comprend bien, ça donne (*grosso-modo*) une courbe de
consommation ascendante lorsque l'on baisse la fréquence, et une courbe
de consommation descendante lorsque l'on baisse le pourcentage
d'occupation du CPU. L'exercice consiste donc à trouver le point
d'équilibre, celui où les deux courbes se croisent et qui est le niveau
où ce que l'on gagne en baissant la fréquence n'est pas perdu à cause de
l'augmentation de l'occupation du processeur.

Ben déjà ce que je verrais personnellement comme idée, mais je précise
que je n'ai aucune idée quant à la faisabilité de la chose, c'est un
mode test qui ressemblerait plus ou moins à ça :

pour 1 à 10
pour 1 à 10
1) forcer une montée en charge du processeur (quitte à faire une banale
imbriquation de boucle for[1]).
2) tracer en interne à interval très court la charge du processeur
et sa consommation.
3) Rester à se palier pendant X minutes pour avoir un échantillon
le plus représentatif possible.
4) A la fin du palier calculer la charge moyenne et la consommation
moyenne (ou s/moyenne/médianne/ peut-être), loguer le résultat
et la fréquence
5) Passer au niveau suivant en augmentant un peu/beaucoup plus la
charge simulée du processeur.
fin pour
Descendre la fréquence
fin pour

Au final, en étudiant les logs l'utilisateur serait en mesure de trouver
le point d'équilibre correspondant à son processeur. Et comme le test
se serait effectué en simulant plusieurs niveau d'occupation du processeur,
il devrait pouvoir l'adapter à sa propre utilisation de la machine.
Même si l'occupation simulée reste faible cela devrait donner une idée
de la courbe telle qu'elle serait à un niveau d'occupation réel. Peut-être
même qu'un matheu pourrait partir de là et générer statistiquement la
courbe correspondant plus ou moins à une occupation donnée.

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.

D'où l'intérêt, si c'est faisable, du mode test qui précède, pour
permettre à l'utilisateur de trouver la bonne valeur.

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.

Ce qui n'est réalisable que si la charge reste constante sur le long
terme, non ? Personnellement étant complètement barge, il peut m'arriver
de faire monter des machines à 95% de charges en pleine nuit, et qu'elles
ne tournent qu'à 5% le reste du temps.

J'espère quand-même arriver à implémenter des améliorations à powerd. Vos
conseils sont donc les bienvenus.

Conseils, oulala, c'est trop compliqué pour moi, mais des idées, ça
c'est possible, même les plus folles.

Par contre, tant que j'y suis, une chose à laquelle j'ai pensé ce matin.
Un PC ne veut pas démarrer s'il n'a pas de carte graphique et s'il n'y a
pas de clavier. Mais lorsqu'il est utilisé en tant que serveur, ni l'un
ni l'autre ne servent vraiment, sauf grosse maintenance.
Donc ce que j'aimerais arriver à faire, c'est pouvoir couper
l'alimentation de la carte graphique et celle du clavier, et la réactiver
si vraiment un jour j'en ai besoin. C'est faisable ce genre de choses ?
J'aurais bien cherché par moi-même, mais j'avoue ne pas avoir le moindre
début d'idée de la façon dont je pourrais formuler la question (surtout
en anglais) et/ou de où je pourrais éventuellement trouver les infos.

[1]
[en perl, parce que je suis archi nul en C/C++]
[$internal permet de faire varier le nombre d'imbrication]
sub loop
{
my $internal = shift;
return unless --$internal;
for( my $i = 0 ; $i < 99999999 ; $i++)
( &loop( $internal ); }
}

Cyrille Szymanski devait dire quelque chose comme ceci :

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%,

Donc si je comprend bien, ça donne (*grosso-modo*) une courbe de
consommation ascendante lorsque l'on baisse la fréquence, et une courbe
de consommation descendante lorsque l'on baisse le pourcentage
d'occupation du CPU. L'exercice consiste donc à trouver le point
d'équilibre, celui où les deux courbes se croisent et qui est le niveau
où ce que l'on gagne en baissant la fréquence n'est pas perdu à cause de
l'augmentation de l'occupation du processeur.

Ben déjà ce que je verrais personnellement comme idée, mais je précise
que je n'ai aucune idée quant à la faisabilité de la chose, c'est un
mode test qui ressemblerait plus ou moins à ça :

pour 1 à 10
pour 1 à 10
1) forcer une montée en charge du processeur (quitte à faire une banale
imbriquation de boucle for[1]).
2) tracer en interne à interval très court la charge du processeur
et sa consommation.
3) Rester à se palier pendant X minutes pour avoir un échantillon
le plus représentatif possible.
4) A la fin du palier calculer la charge moyenne et la consommation
moyenne (ou s/moyenne/médianne/ peut-être), loguer le résultat
et la fréquence
5) Passer au niveau suivant en augmentant un peu/beaucoup plus la
charge simulée du processeur.
fin pour
Descendre la fréquence
fin pour

Au final, en étudiant les logs l'utilisateur serait en mesure de trouver
le point d'équilibre correspondant à son processeur. Et comme le test
se serait effectué en simulant plusieurs niveau d'occupation du processeur,
il devrait pouvoir l'adapter à sa propre utilisation de la machine.
Même si l'occupation simulée reste faible cela devrait donner une idée
de la courbe telle qu'elle serait à un niveau d'occupation réel. Peut-être
même qu'un matheu pourrait partir de là et générer statistiquement la
courbe correspondant plus ou moins à une occupation donnée.

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.

D'où l'intérêt, si c'est faisable, du mode test qui précède, pour
permettre à l'utilisateur de trouver la bonne valeur.

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.

Ce qui n'est réalisable que si la charge reste constante sur le long
terme, non ? Personnellement étant complètement barge, il peut m'arriver
de faire monter des machines à 95% de charges en pleine nuit, et qu'elles
ne tournent qu'à 5% le reste du temps.

J'espère quand-même arriver à implémenter des améliorations à powerd. Vos
conseils sont donc les bienvenus.

Conseils, oulala, c'est trop compliqué pour moi, mais des idées, ça
c'est possible, même les plus folles.

Par contre, tant que j'y suis, une chose à laquelle j'ai pensé ce matin.
Un PC ne veut pas démarrer s'il n'a pas de carte graphique et s'il n'y a
pas de clavier. Mais lorsqu'il est utilisé en tant que serveur, ni l'un
ni l'autre ne servent vraiment, sauf grosse maintenance.
Donc ce que j'aimerais arriver à faire, c'est pouvoir couper
l'alimentation de la carte graphique et celle du clavier, et la réactiver
si vraiment un jour j'en ai besoin. C'est faisable ce genre de choses ?
J'aurais bien cherché par moi-même, mais j'avoue ne pas avoir le moindre
début d'idée de la façon dont je pourrais formuler la question (surtout
en anglais) et/ou de où je pourrais éventuellement trouver les infos.

[1]
[en perl, parce que je suis archi nul en C/C++]
[$internal permet de faire varier le nombre d'imbrication]
sub loop
{
my $internal = shift;
return unless --$internal;
for( my $i = 0 ; $i < 99999999 ; $i++)
( &loop( $internal ); }
}

Vous avez filtré cet utilisateur ! Consultez son message

Cyrille Szymanski devait dire quelque chose comme ceci :

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%,

Donc si je comprend bien, ça donne (*grosso-modo*) une courbe de
consommation ascendante lorsque l'on baisse la fréquence, et une courbe
de consommation descendante lorsque l'on baisse le pourcentage
d'occupation du CPU. L'exercice consiste donc à trouver le point
d'équilibre, celui où les deux courbes se croisent et qui est le niveau
où ce que l'on gagne en baissant la fréquence n'est pas perdu à cause de
l'augmentation de l'occupation du processeur.

Ben déjà ce que je verrais personnellement comme idée, mais je précise
que je n'ai aucune idée quant à la faisabilité de la chose, c'est un
mode test qui ressemblerait plus ou moins à ça :

pour 1 à 10
pour 1 à 10
1) forcer une montée en charge du processeur (quitte à faire une banale
imbriquation de boucle for[1]).
2) tracer en interne à interval très court la charge du processeur
et sa consommation.
3) Rester à se palier pendant X minutes pour avoir un échantillon
le plus représentatif possible.
4) A la fin du palier calculer la charge moyenne et la consommation
moyenne (ou s/moyenne/médianne/ peut-être), loguer le résultat
et la fréquence
5) Passer au niveau suivant en augmentant un peu/beaucoup plus la
charge simulée du processeur.
fin pour
Descendre la fréquence
fin pour

Au final, en étudiant les logs l'utilisateur serait en mesure de trouver
le point d'équilibre correspondant à son processeur. Et comme le test
se serait effectué en simulant plusieurs niveau d'occupation du processeur,
il devrait pouvoir l'adapter à sa propre utilisation de la machine.
Même si l'occupation simulée reste faible cela devrait donner une idée
de la courbe telle qu'elle serait à un niveau d'occupation réel. Peut-être
même qu'un matheu pourrait partir de là et générer statistiquement la
courbe correspondant plus ou moins à une occupation donnée.

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.

D'où l'intérêt, si c'est faisable, du mode test qui précède, pour
permettre à l'utilisateur de trouver la bonne valeur.

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.

Ce qui n'est réalisable que si la charge reste constante sur le long
terme, non ? Personnellement étant complètement barge, il peut m'arriver
de faire monter des machines à 95% de charges en pleine nuit, et qu'elles
ne tournent qu'à 5% le reste du temps.

J'espère quand-même arriver à implémenter des améliorations à powerd. Vos
conseils sont donc les bienvenus.

Conseils, oulala, c'est trop compliqué pour moi, mais des idées, ça
c'est possible, même les plus folles.

Par contre, tant que j'y suis, une chose à laquelle j'ai pensé ce matin.
Un PC ne veut pas démarrer s'il n'a pas de carte graphique et s'il n'y a
pas de clavier. Mais lorsqu'il est utilisé en tant que serveur, ni l'un
ni l'autre ne servent vraiment, sauf grosse maintenance.
Donc ce que j'aimerais arriver à faire, c'est pouvoir couper
l'alimentation de la carte graphique et celle du clavier, et la réactiver
si vraiment un jour j'en ai besoin. C'est faisable ce genre de choses ?
J'aurais bien cherché par moi-même, mais j'avoue ne pas avoir le moindre
début d'idée de la façon dont je pourrais formuler la question (surtout
en anglais) et/ou de où je pourrais éventuellement trouver les infos.

[1]
[en perl, parce que je suis archi nul en C/C++]
[$internal permet de faire varier le nombre d'imbrication]
sub loop
{
my $internal = shift;
return unless --$internal;
for( my $i = 0 ; $i < 99999999 ; $i++)
( &loop( $internal ); }
}

patpro ~ patrick proniewski

14/01/2007 à 17:02

In article ,
Patrick Lamaizière wrote:

Cpufreq.ko ajoute deux drivers (chez moi sur un centrino) et supprime
l'acpi_throttle :
est0: <Enhanced SpeedStep Frequency Control> on cpu0
p4tcc0: <CPU Frequency Thermal Control> on cpu0

"Est" va plus loin, il réduit aussi la tension du processeur.

ha ho, avec ça peut être que la température de mes processeurs pourrait
baisser.

Quant-à
p4tcc ça devrait être lié au "passive cooling" du processeur. Mais je
me demande comment ça s'utilise.

d'après ce que je lis à droite et à gauche, j'en déduis que ça permet de
faire du throttling en fonction de la température.

En même temps je vois tout ce qui est dit ici, et je me demande dans
quelle mesure tout ceci est encore pertinent avec les CPU qui sont
sensés gérer leur consommation et leur fréquence eux mêmes.
Notamment, les CPU "sossaman" ont ce qu'il faut dans le ventre pour que
chaque core puisse passer en C1 indépendamment des autres, ils disposent
de la techno Enhanced Intel SpeedStep Technology, et d'autres gadgets de
Thermal Monitoring.

patpro

--
http://www.patpro.net/

patpro ~ patrick proniewski

14/01/2007 à 17:17

In article ,
Cyrille Szymanski wrote:

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.

Si je comprends bien ce que tu veux dire, un CPU donné consomme plus en
tournant à fond 10 secondes à 200 MHz plutôt qu'une seconde à 2GHz.
C'est probable. Mais l'échantillonnage de powerd est d'une demie
seconde, donc en théorie tu tournes à fond 0,5 secondes à 200 MHz, tu
passes au plateau suivant, tu tournes à fond 0,5 secondes, plateau
suivant.. avec 4 plateaux, tu arrives en 2 secondes à ton max de
vitesse, et probablement que ton calcul est fini.

Je pense que l'idée de Stéphane d'avoir un script/programme qui évalue
sur le terrain le comportement d'une machine donnée est intéressante.

patpro

--
http://www.patpro.net/

In article <Xns98B89E89924B9cns2cnsinvalid@212.27.60.37>,
Cyrille Szymanski <cns2@cns.invalid> wrote:

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.

Si je comprends bien ce que tu veux dire, un CPU donné consomme plus en
tournant à fond 10 secondes à 200 MHz plutôt qu'une seconde à 2GHz.
C'est probable. Mais l'échantillonnage de powerd est d'une demie
seconde, donc en théorie tu tournes à fond 0,5 secondes à 200 MHz, tu
passes au plateau suivant, tu tournes à fond 0,5 secondes, plateau
suivant.. avec 4 plateaux, tu arrives en 2 secondes à ton max de
vitesse, et probablement que ton calcul est fini.

Je pense que l'idée de Stéphane d'avoir un script/programme qui évalue
sur le terrain le comportement d'une machine donnée est intéressante.

patpro

--
http://www.patpro.net/

Vous avez filtré cet utilisateur ! Consultez son message

In article ,
Cyrille Szymanski wrote:

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.

Si je comprends bien ce que tu veux dire, un CPU donné consomme plus en
tournant à fond 10 secondes à 200 MHz plutôt qu'une seconde à 2GHz.
C'est probable. Mais l'échantillonnage de powerd est d'une demie
seconde, donc en théorie tu tournes à fond 0,5 secondes à 200 MHz, tu
passes au plateau suivant, tu tournes à fond 0,5 secondes, plateau
suivant.. avec 4 plateaux, tu arrives en 2 secondes à ton max de
vitesse, et probablement que ton calcul est fini.

Je pense que l'idée de Stéphane d'avoir un script/programme qui évalue
sur le terrain le comportement d'une machine donnée est intéressante.

patpro

--
http://www.patpro.net/

patpro ~ patrick proniewski

14/01/2007 à 17:22

In article ,
Stephane Catteau wrote:

Par contre, tant que j'y suis, une chose à laquelle j'ai pensé ce matin.
Un PC ne veut pas démarrer s'il n'a pas de carte graphique et s'il n'y a
pas de clavier.

pour le clavier ça peut se régler dans le Bios. En tout cas c'est comme
ça que j'avais procédé il y a un moment sur un vieux PC.
Pour la carte vidéo, avec un peu de chance c'est pareil, mais c'est plus
délicat parce que c'est pas hotplug ;)

patpro

--
http://www.patpro.net/

patpro ~ patrick proniewski

14/01/2007 à 17:25

In article ,
Patrick Lamaizière wrote:

Patrick Lamaizière :

et bien les températures ne bougent pas... dommage.
CPU0 stable à 35,5 °C
CPU1 stable à 30 °C
Carte mère stable à 33 °C

Faudrait que j'essai.

J'ai essayé sur mon centrino sans cpufreq.ko et la température est
stable. À mon avis un cpu idle ne consomme pas plus que s'il est occupé
à moindre fréquence. Par contre avec le Speed Step la température chute
d'environ 9°C.

je vais tester ça alors, mais si il faut rebooter ça va peut être
attendre.

patpro

--
http://www.patpro.net/

Stephane Catteau

14/01/2007 à 18:30

patpro ~ patrick proniewski devait dire quelque chose comme ceci :

Par contre, tant que j'y suis, une chose à laquelle j'ai pensé ce matin.
Un PC ne veut pas démarrer s'il n'a pas de carte graphique et s'il n'y a
pas de clavier.

pour le clavier ça peut se régler dans le Bios. En tout cas c'est comme
ça que j'avais procédé il y a un moment sur un vieux PC.
Pour la carte vidéo, avec un peu de chance c'est pareil, mais c'est plus
délicat parce que c'est pas hotplug ;)

Ca me plait pas trop comme solution, parce que ça oblige à rebooter.
Le P75 est ma machine la plus capricieuse ; je suis obligé de monter
deux fois la carte réseau pour qu'elle accepte d'accrocher le switch.
Et parfois ça ne suffit pas, il faut la monter une troisième fois voir
plus (le maxi a été de sept fois :-/). De même qu'il lui arrive parfois
de redescendre toute seule[1].
Bon, j'ai réglé ça avec un script en crontab pour (re)monter la carte
jusqu'à ce qu'elle tienne, mais du coup je suis relativement échaudé.
C'est pour ça que je préfèrerais une solution qui évite le reboot juste
parce que je ne peux plus gérer la machine par le réseau. Surtout
qu'avec les restrictions que j'ai mises en login class sur les comptes
ayant un acces SSH, il y a certaines choses qui ne peuvent être faites
qu'en console.

[1]
Et j'ai eu beau faire, quelque soit la carte et le slot PCI de la
machine, c'est pareil, alors que les cartes marchent impécable sur les
autres machines.

patpro ~ patrick proniewski

14/01/2007 à 19:31

In article ,
Patrick Lamaizière wrote:

Patrick Lamaizière :

et bien les températures ne bougent pas... dommage.
CPU0 stable à 35,5 °C
CPU1 stable à 30 °C
Carte mère stable à 33 °C

Faudrait que j'essai.

J'ai essayé sur mon centrino sans cpufreq.ko et la température est
stable. À mon avis un cpu idle ne consomme pas plus que s'il est occupé
à moindre fréquence. Par contre avec le Speed Step la température chute
d'environ 9°C.

Pas pu essayé sur mon p3, je n'ai pas la température CPU. Il faut
charger le cpufreq.ko au boot aussi, après ça ne fonctionne pas :
«
kernel: acpi_perf0: <ACPI CPU Frequency Control> on cpu0
kernel: acpi_perf0: failed in PERF_STATUS attach
kernel: device_attach: acpi_perf0 attach returned 6
»

Bon, alors j'ai testé plusieurs choses :

- charger le module sans rebooter. Cela a fonctionné en partie.
Notamment, dev.cpu.0.freq_levels est passé d'une liste de 8 fréquences à
une liste d'environ 20 fréquences. Ensuite, j'ai relancé powerd, qui a
bien accroché une de ces fréquences, mais ensuite impossible de la faire
varier dynamiquement. La machine était bloquée à 185 MHz.
J'ai tenté de rebooter, mais ça a bloqué vers la fin de l'extinction ->
hard reboot.

- comme j'avais ajouté la ligne adhoc dans loader.conf avant de faire
mes bêtises, le reboot a chargé cpufreq. J'ai donc testé la même chose
avec reboot : c'est pas vraiment mieux. Je me retrouve avec ma liste
dev.cpu.0.freq_levels de 8 fréquences, mais powerd fait son boulot. Il
semble que mes CPU ne sont pas correctement reconnus :

dmesg :

cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr a1e0a1e06000a1e
device_attach: est0 attach returned 6
p4tcc0: <CPU Frequency Thermal Control> on cpu0

maintenant j'ai ça :

sysctl :

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: 208

dev.p4tcc.0.%parent: cpu0

dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0

(idem pour cpu1/2/3)

Y a t'il un moyen d'arranger ça ?
J'ai noté dans la description du port "est" que cela ne fonctionne pas
en SMP, est ce que l'implémentation du module cpufreq a la même
limitation ?

patpro

--
http://www.patpro.net/

In article <Xns64413C8F6B30Eplam@nulle.invalid>,
Patrick Lamaizière <adresse@est.invalid> wrote:

Patrick Lamaizière :

et bien les températures ne bougent pas... dommage.
CPU0 stable à 35,5 °C
CPU1 stable à 30 °C
Carte mère stable à 33 °C

Faudrait que j'essai.

J'ai essayé sur mon centrino sans cpufreq.ko et la température est
stable. À mon avis un cpu idle ne consomme pas plus que s'il est occupé
à moindre fréquence. Par contre avec le Speed Step la température chute
d'environ 9°C.

Pas pu essayé sur mon p3, je n'ai pas la température CPU. Il faut
charger le cpufreq.ko au boot aussi, après ça ne fonctionne pas :
«
kernel: acpi_perf0: <ACPI CPU Frequency Control> on cpu0
kernel: acpi_perf0: failed in PERF_STATUS attach
kernel: device_attach: acpi_perf0 attach returned 6
»

Bon, alors j'ai testé plusieurs choses :

- charger le module sans rebooter. Cela a fonctionné en partie.
Notamment, dev.cpu.0.freq_levels est passé d'une liste de 8 fréquences à
une liste d'environ 20 fréquences. Ensuite, j'ai relancé powerd, qui a
bien accroché une de ces fréquences, mais ensuite impossible de la faire
varier dynamiquement. La machine était bloquée à 185 MHz.
J'ai tenté de rebooter, mais ça a bloqué vers la fin de l'extinction ->
hard reboot.

- comme j'avais ajouté la ligne adhoc dans loader.conf avant de faire
mes bêtises, le reboot a chargé cpufreq. J'ai donc testé la même chose
avec reboot : c'est pas vraiment mieux. Je me retrouve avec ma liste
dev.cpu.0.freq_levels de 8 fréquences, mais powerd fait son boulot. Il
semble que mes CPU ne sont pas correctement reconnus :

dmesg :

cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr a1e0a1e06000a1e
device_attach: est0 attach returned 6
p4tcc0: <CPU Frequency Thermal Control> on cpu0

maintenant j'ai ça :

sysctl :

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: 208

dev.p4tcc.0.%parent: cpu0

dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0

(idem pour cpu1/2/3)

Y a t'il un moyen d'arranger ça ?
J'ai noté dans la description du port "est" que cela ne fonctionne pas
en SMP, est ce que l'implémentation du module cpufreq a la même
limitation ?

patpro

--
http://www.patpro.net/

Vous avez filtré cet utilisateur ! Consultez son message

In article ,
Patrick Lamaizière wrote:

Patrick Lamaizière :

et bien les températures ne bougent pas... dommage.
CPU0 stable à 35,5 °C
CPU1 stable à 30 °C
Carte mère stable à 33 °C

Faudrait que j'essai.

J'ai essayé sur mon centrino sans cpufreq.ko et la température est
stable. À mon avis un cpu idle ne consomme pas plus que s'il est occupé
à moindre fréquence. Par contre avec le Speed Step la température chute
d'environ 9°C.

Pas pu essayé sur mon p3, je n'ai pas la température CPU. Il faut
charger le cpufreq.ko au boot aussi, après ça ne fonctionne pas :
«
kernel: acpi_perf0: <ACPI CPU Frequency Control> on cpu0
kernel: acpi_perf0: failed in PERF_STATUS attach
kernel: device_attach: acpi_perf0 attach returned 6
»

Bon, alors j'ai testé plusieurs choses :

- charger le module sans rebooter. Cela a fonctionné en partie.
Notamment, dev.cpu.0.freq_levels est passé d'une liste de 8 fréquences à
une liste d'environ 20 fréquences. Ensuite, j'ai relancé powerd, qui a
bien accroché une de ces fréquences, mais ensuite impossible de la faire
varier dynamiquement. La machine était bloquée à 185 MHz.
J'ai tenté de rebooter, mais ça a bloqué vers la fin de l'extinction ->
hard reboot.

- comme j'avais ajouté la ligne adhoc dans loader.conf avant de faire
mes bêtises, le reboot a chargé cpufreq. J'ai donc testé la même chose
avec reboot : c'est pas vraiment mieux. Je me retrouve avec ma liste
dev.cpu.0.freq_levels de 8 fréquences, mais powerd fait son boulot. Il
semble que mes CPU ne sont pas correctement reconnus :

dmesg :

cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr a1e0a1e06000a1e
device_attach: est0 attach returned 6
p4tcc0: <CPU Frequency Thermal Control> on cpu0

maintenant j'ai ça :

sysctl :

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: 208

dev.p4tcc.0.%parent: cpu0

dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0

(idem pour cpu1/2/3)

Y a t'il un moyen d'arranger ça ?
J'ai noté dans la description du port "est" que cela ne fonctionne pas
en SMP, est ce que l'implémentation du module cpufreq a la même
limitation ?

patpro

--
http://www.patpro.net/

Cyrille Szymanski

14/01/2007 à 19:47

Stephane Catteau wrote in
news::

L'exercice consiste donc à trouver le point
d'équilibre, celui où les deux courbes se croisent et qui est le
niveau où ce que l'on gagne en baissant la fréquence n'est pas perdu à
cause de l'augmentation de l'occupation du processeur.

Effectivement un mode test me paraît indispensable pour étaloner les
paramètres et bien modéliser comment réagit le matériel. Mais entre aussi
en jeu la partie prédictive le l'algorithme... et le compromis à trouver
entre un système réactif et un système qui a une grande autonomie.

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.

Ce qui n'est réalisable que si la charge reste constante sur le long
terme, non ? Personnellement étant complètement barge, il peut
m'arriver de faire monter des machines à 95% de charges en pleine
nuit, et qu'elles ne tournent qu'à 5% le reste du temps.

Si tu sais quand tu vas solliciter le processeur, rien ne t'empêche de
mettre la fréquence à 100% avant d'exécuter ton script, et de la remettre
au minimum juste après.

Mais dans le cas général c'est un problème de prédiction. Du point de vue
théorique, l'hypothèse la plus raisonnable à faire est de considérer que
l'espérance de charge future est égale à la valeur précédemment observée.
Cela revient effectivement à prédire une charge CPU constante, égale à sa
moyenne. Ensuite le tout est de réactualiser la moyenne quand il faut.

C'est ce que l'on trouve dans la littérature, c'est aussi ce que j'ai
observé.

J'espère quand-même arriver à implémenter des améliorations à powerd.
Vos conseils sont donc les bienvenus.

Conseils, oulala, c'est trop compliqué pour moi, mais des idées, ça
c'est possible, même les plus folles.

Oui, cf un post sur acpi@

http://docs.freebsd.org/cgi/getmsg.cgi?fetch788+0+archive/2007/freebsd-
acpi/20070107.freebsd-acpi

Merci pour ce message

--
Cyrille Szymanski

Stephane Catteau <steph.nospam@sc4x.net> wrote in
news:mn.73e57d71cdbd5b9d.30736@sc4x.org:

L'exercice consiste donc à trouver le point
d'équilibre, celui où les deux courbes se croisent et qui est le
niveau où ce que l'on gagne en baissant la fréquence n'est pas perdu à
cause de l'augmentation de l'occupation du processeur.

Effectivement un mode test me paraît indispensable pour étaloner les
paramètres et bien modéliser comment réagit le matériel. Mais entre aussi
en jeu la partie prédictive le l'algorithme... et le compromis à trouver
entre un système réactif et un système qui a une grande autonomie.

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.

Ce qui n'est réalisable que si la charge reste constante sur le long
terme, non ? Personnellement étant complètement barge, il peut
m'arriver de faire monter des machines à 95% de charges en pleine
nuit, et qu'elles ne tournent qu'à 5% le reste du temps.

Si tu sais quand tu vas solliciter le processeur, rien ne t'empêche de
mettre la fréquence à 100% avant d'exécuter ton script, et de la remettre
au minimum juste après.

Mais dans le cas général c'est un problème de prédiction. Du point de vue
théorique, l'hypothèse la plus raisonnable à faire est de considérer que
l'espérance de charge future est égale à la valeur précédemment observée.
Cela revient effectivement à prédire une charge CPU constante, égale à sa
moyenne. Ensuite le tout est de réactualiser la moyenne quand il faut.

C'est ce que l'on trouve dans la littérature, c'est aussi ce que j'ai
observé.

J'espère quand-même arriver à implémenter des améliorations à powerd.
Vos conseils sont donc les bienvenus.

Conseils, oulala, c'est trop compliqué pour moi, mais des idées, ça
c'est possible, même les plus folles.

Oui, cf un post sur acpi@

http://docs.freebsd.org/cgi/getmsg.cgi?fetch788+0+archive/2007/freebsd-
acpi/20070107.freebsd-acpi

Merci pour ce message

--
Cyrille Szymanski

Vous avez filtré cet utilisateur ! Consultez son message

Cyrille Szymanski

14/01/2007 à 20:03

patpro ~ patrick proniewski wrote in
news::

Si je comprends bien ce que tu veux dire, un CPU donné consomme plus
en tournant à fond 10 secondes à 200 MHz plutôt qu'une seconde à 2GHz.
C'est probable.

Oui, le modèle le plus rustique qu'on puisse faire est au moins affine.

Ce que tu dis est à la fois vrai et faux. Tout dépend du point de vue. Si
tu calcules l'énergie consommée par ta tâche de 2 giga cycles (cas 1),
elle sera plus petite à 2 Ghz qu'à 200 MHz. Par contre si ta machine
reste allumée 1 minute quoi qu'il arrive (cas 2), l'énergie totale
consommée sera plus faible en restant tout le temps à 200 MHz.

Mais l'échantillonnage de powerd est d'une demie
seconde, donc en théorie tu tournes à fond 0,5 secondes à 200 MHz, tu
passes au plateau suivant, tu tournes à fond 0,5 secondes, plateau
suivant.. avec 4 plateaux, tu arrives en 2 secondes à ton max de
vitesse, et probablement que ton calcul est fini.

En général les gens veulent la plus grande autonomie possible sur
batterie (cas 2 dont je parle plus haut). La solution est donc de rester
à la fréquence minimale tout le temps. Mais s'ils se paient des bécanes à
2 GHz c'est pas pour les brider à 200 MHz ;-)

Il est tout à fait possible de réagir différemment et de passer à la
vitesse max dès que le processeur est sollicité à plus de 95% pendant un
échantillon. On gagne en réactivité, mais bien-sûr on consommera plus.

Je pense que l'idée de Stéphane d'avoir un script/programme qui évalue
sur le terrain le comportement d'une machine donnée est intéressante.

Oui, cf un post sur acpi@ pour l'idée de définir des profils en
discriminant par modèle de CPU.

http://docs.freebsd.org/cgi/getmsg.cgi?fetch788+0+archive/2007/freebsd-
acpi/20070107.freebsd-acpi

--
Cyrille Szymanski

Eric Masson

15/01/2007 à 14:21

patpro ~ patrick proniewski writes:

'Lut,

Eric, tu nous a répondu sur pas mal de points, as-tu un avis sur le
chargement de cpufreq.ko ?

Euh, moyen ;)

Je n'ai jamais vraiment fait gaffe aux infos renvoyées par l'acpi sur
les thermal zones, la seule chose que je peux dire est que sur mon
portable, il me semble que les ventilos se déclenchent moins souvent
qu'en l'absence de cpufreq/powerd.

Désolé.

--
je suis ÿffffe9tudiant en ÿffffe9cole d'ingÿffffe9nieurÿffffe0Lyon et
je suis totalement bloquÿffffe9 dansla programmation d'un applicatif
qui permettrait dedessiner des sphÿffffe8res ombrÿffffe9es.
-+- clÿffffe9ment in GNU - Tremblement de teÿffffrre en solde -+-

[FreeBSD] powerd est-il si interessant ?

10 réponses

Veuillez sélectionner un problème