[FreeBSD] powerd est-il si interessant ?

Ducrot Bruno

15/01/2007 à 17:09

On Sun, 14 Jan 2007 16:23:00 +0100, Thierry Herbelot
<------%------thierry------% wrote:

Eric Masson wrote:

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.

j'avais aussi regardé pour mon Athlon (AMD 32 bits), et seuls les
processeurs pour portables (Turion ?) contenaient la fonction "hard" qui
permet le changement de fréquence.

Les durons, les athlon et les athlon-xp sont supportes, a condition
toutefois d'etre dans la version mobile, ou la version low-voltage
pour les versions desktops. Les K6-III peuvent egalement changer a
la fois de frequence et de voltage, mais ne sont pas supportes par
FreeBSD, ni aucun autre OS libre a ma connaissance. Le pilote pour
ce dernier fourni dans OpenBSD, par exemple, ne change pas le
voltage et du coup on ne voit pas l'interet de le porter pour
FreeBSD.

--
Bruno Ducrot

-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.

Stephane Catteau

15/01/2007 à 17:24

Cyrille Szymanski devait dire quelque chose comme ceci :

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.

Ah vi, c'est pas bête ça.

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.

Si je me base sur ma propre utilisation, la charge monte
progressivement, puis arrivée à son maximum elle fait des creux, mais
rarement des bosses, et enfin elle redescend plus brusquement qu'elle
n'était montée.
En fait graph ça donnerait quelque chose comme ça (je fait un palier
plat pour simplifier) :
____
/ |
/ |

Reporté sur l'utilisation à long terme, chez moi ça donne quelque
chose comme :

______
/ |
___/|____/|___/ |________/|___/|________
/ |
^^ ^^ ^^ ^^ ^^ ^^ ^^
^^ ^^ ^^ monté en charge ^^ ^^ arrêt de la machine
^^ ^^ ^^ ^^ ^^
^^ Piques dû par exemple à cron /
^^
Charge initiale de la machine

Evidement, la courbe est ici symbolique, dans la réalité elle est
moins lisse que cela.

Pour la suite, je pars du principe qu'une fréquence un peu trop élevée
est préférable à une charge trop importante.

Déjà, la première chose que je constate, c'est qu'il y a des montées
en charge qui sont prévisibles. Pourquoi ne pas tout simplement parser
au démarrage de powerd les fichiers comme la crontab ? S'il y a un
évènement prévu pour par exemple 1h05, on sait dès le début que la
charge va monter à ce moment là.
De même, il y a des montées en charge prévisibles, comme par exemple
lorsque ntpd interroge un serveur NTP pour vérifier que la machine est
toujours à l'heure. Je vois deux moyens pour prévoir ces montées en
charge.
La première est la plus simple, mais la plus limitative, elle consiste
à procéder comme pour la crontab, une analyse des fichiers de
configuration des démons succeptibles de la provoquer. Simple parce
qu'elle ne demande aucun algorythme compliqué, mais limitative
puisqu'il faut suivre l'évolution des programmes pour s'adapter aux
changements dans le fichier de configuration et qu'il faut tenir compte
de tous les programmes succeptibles d'agir de cette façon, même les
scripts à la noix (j'ai trois démons perl qui tourne chez moi).
La seconde méthode pour prévoir ces montées en charge est d'étudier le
comportement de la machine, pour s'apercevoir que la charge augmente à
intervale régulier et qu'elle augmente sensiblement de la même valeur à
chaque fois.
Ces montées en charge étant prévisibles, rien n'empèche (si ce n'est
peut-être la compléxité des algorythmes pour gérer cette prédictivité)
powerd d'agir en augmentant la fréquence juste avant qu'elles
n'interviennent.

La seconde chose que je constate, c'est que, lors des taches non
prédictibles, la montée en charge est sensiblement constante, la charge
maximum est rarement dépassée, et la baisse de charge est relativement
brutale. Etant du genre paranoïaque, j'aurais personnellement tendance
à me placer toujours en avance par rapport à l'avenir.
La montée en charge peut-être observée en comparant les x dernières
mesures (x < x1 < x2 ... < xn).
Si la charge n'est pas arrivée à son palier, la charge suivante
tournera autour de x + ( ( x1 + x2 ... + xn ) / n ).
Si la charge est arrivée à son palier, la charge suivante ne sera pas
supérieure à x, mais elle ne sera pas très inférieur non plus. Prévoir
une charge de x + ( ( x1 + x2 ... + xn ) / n ) serait superflu, mais en
offrant potentiellement une fréquence supérieur cela limiterait la
dégradation des performances tout en assurant que la charge du
processeur restera raisonnable.
Même chose si ce n'était qu'un pique et que la charge suivante baisse
sensiblement.

La baisse de charge est, d'après ce que moi j'ai constaté, plus facile
encore à observée. La différence entre x et x1 étant plus importante, n
peut être plus petit. Dans un tel cas, j'aurais tendance à considérer
que la charge sera égale à x, pour les mêmes raison qu'au-dessus.

Le vrai problème, c'est le palier. La charge diminue parfois, mais ne
dépasse que rarement son maximum. Là, et bien en ce moment je suis
entrain d'écouter de la musique, et j'ai la réponse sous les yeux,
c'est la représentation en barre du spectre de la musique. Il y a un
petit trait qui indique le niveau maximum atteint par chaque barre,
trait qui monte en suivant la barre, mais qui reste un instant à son
niveau maximum lorsque la barre descend.
Rapporté à powerd, ça donnerait quelque chose comme : Tant que la
charge est supérieure à la charge moyenne constatée et qu'elle est
supérieur à 90% (à définir) de la charge précédente, considérer que
l'on est toujours sur le palier et que la charge va remonter dans un
instant.

En fait, ce qui découle de tout ça, c'est que, amtha, l'algorythme ne
doit pas simplement tenir compte de l'état précédent, mais arriver à
définir, au fil du temps, un profil de la machine. Trouver les piques
récurents pour les prévenir, et déterminer quelle est la charge moyenne
lorsque l'utilisateur ne fait rien de particulier (comprendre "rien de
plus que d'habitude"). Ou plus exactement entre quelles limites (basse
et haute) se situe cette charge moyenne, puisqu'elle varie, mais a
tendance à rester confinée entre deux valeurs qu'elle ne dépasse jamais
si aucun évènement imprévu n'intervient.

Grace à cette double limite, il devient possible de déterminer qu'il y
a une montée en charge qui risque d'être importante, parce que la
charge est de 20% (à définir aussi) supérieur à la limite haute. A
l'inverse, si la charge descend sensiblement en dessous de la limite
basse, il y a fort à parier que l'utilisateur a arrêté momentanément
d'utiliser la machine (pour répondre au téléphone par exemple), et
qu'il est donc préférable de baisser fortement la fréquence, quitte à
risquer une charge trop importante pour le processeur.

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

On a donc clairement pas les mêmes comportements ;-)

Merci pour ce message

De rien.

Cyrille Szymanski devait dire quelque chose comme ceci :

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.

Ah vi, c'est pas bête ça.

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.

Si je me base sur ma propre utilisation, la charge monte
progressivement, puis arrivée à son maximum elle fait des creux, mais
rarement des bosses, et enfin elle redescend plus brusquement qu'elle
n'était montée.
En fait graph ça donnerait quelque chose comme ça (je fait un palier
plat pour simplifier) :
____
/ |
/ |

Reporté sur l'utilisation à long terme, chez moi ça donne quelque
chose comme :

______
/ |
___/|____/|___/ |________/|___/|________
/ |
^^ ^^ ^^ ^^ ^^ ^^ ^^
^^ ^^ ^^ monté en charge ^^ ^^ arrêt de la machine
^^ ^^ ^^ ^^ ^^
^^ Piques dû par exemple à cron /
^^
Charge initiale de la machine

Evidement, la courbe est ici symbolique, dans la réalité elle est
moins lisse que cela.

Pour la suite, je pars du principe qu'une fréquence un peu trop élevée
est préférable à une charge trop importante.

Déjà, la première chose que je constate, c'est qu'il y a des montées
en charge qui sont prévisibles. Pourquoi ne pas tout simplement parser
au démarrage de powerd les fichiers comme la crontab ? S'il y a un
évènement prévu pour par exemple 1h05, on sait dès le début que la
charge va monter à ce moment là.
De même, il y a des montées en charge prévisibles, comme par exemple
lorsque ntpd interroge un serveur NTP pour vérifier que la machine est
toujours à l'heure. Je vois deux moyens pour prévoir ces montées en
charge.
La première est la plus simple, mais la plus limitative, elle consiste
à procéder comme pour la crontab, une analyse des fichiers de
configuration des démons succeptibles de la provoquer. Simple parce
qu'elle ne demande aucun algorythme compliqué, mais limitative
puisqu'il faut suivre l'évolution des programmes pour s'adapter aux
changements dans le fichier de configuration et qu'il faut tenir compte
de tous les programmes succeptibles d'agir de cette façon, même les
scripts à la noix (j'ai trois démons perl qui tourne chez moi).
La seconde méthode pour prévoir ces montées en charge est d'étudier le
comportement de la machine, pour s'apercevoir que la charge augmente à
intervale régulier et qu'elle augmente sensiblement de la même valeur à
chaque fois.
Ces montées en charge étant prévisibles, rien n'empèche (si ce n'est
peut-être la compléxité des algorythmes pour gérer cette prédictivité)
powerd d'agir en augmentant la fréquence juste avant qu'elles
n'interviennent.

La seconde chose que je constate, c'est que, lors des taches non
prédictibles, la montée en charge est sensiblement constante, la charge
maximum est rarement dépassée, et la baisse de charge est relativement
brutale. Etant du genre paranoïaque, j'aurais personnellement tendance
à me placer toujours en avance par rapport à l'avenir.
La montée en charge peut-être observée en comparant les x dernières
mesures (x < x1 < x2 ... < xn).
Si la charge n'est pas arrivée à son palier, la charge suivante
tournera autour de x + ( ( x1 + x2 ... + xn ) / n ).
Si la charge est arrivée à son palier, la charge suivante ne sera pas
supérieure à x, mais elle ne sera pas très inférieur non plus. Prévoir
une charge de x + ( ( x1 + x2 ... + xn ) / n ) serait superflu, mais en
offrant potentiellement une fréquence supérieur cela limiterait la
dégradation des performances tout en assurant que la charge du
processeur restera raisonnable.
Même chose si ce n'était qu'un pique et que la charge suivante baisse
sensiblement.

La baisse de charge est, d'après ce que moi j'ai constaté, plus facile
encore à observée. La différence entre x et x1 étant plus importante, n
peut être plus petit. Dans un tel cas, j'aurais tendance à considérer
que la charge sera égale à x, pour les mêmes raison qu'au-dessus.

Le vrai problème, c'est le palier. La charge diminue parfois, mais ne
dépasse que rarement son maximum. Là, et bien en ce moment je suis
entrain d'écouter de la musique, et j'ai la réponse sous les yeux,
c'est la représentation en barre du spectre de la musique. Il y a un
petit trait qui indique le niveau maximum atteint par chaque barre,
trait qui monte en suivant la barre, mais qui reste un instant à son
niveau maximum lorsque la barre descend.
Rapporté à powerd, ça donnerait quelque chose comme : Tant que la
charge est supérieure à la charge moyenne constatée et qu'elle est
supérieur à 90% (à définir) de la charge précédente, considérer que
l'on est toujours sur le palier et que la charge va remonter dans un
instant.

En fait, ce qui découle de tout ça, c'est que, amtha, l'algorythme ne
doit pas simplement tenir compte de l'état précédent, mais arriver à
définir, au fil du temps, un profil de la machine. Trouver les piques
récurents pour les prévenir, et déterminer quelle est la charge moyenne
lorsque l'utilisateur ne fait rien de particulier (comprendre "rien de
plus que d'habitude"). Ou plus exactement entre quelles limites (basse
et haute) se situe cette charge moyenne, puisqu'elle varie, mais a
tendance à rester confinée entre deux valeurs qu'elle ne dépasse jamais
si aucun évènement imprévu n'intervient.

Grace à cette double limite, il devient possible de déterminer qu'il y
a une montée en charge qui risque d'être importante, parce que la
charge est de 20% (à définir aussi) supérieur à la limite haute. A
l'inverse, si la charge descend sensiblement en dessous de la limite
basse, il y a fort à parier que l'utilisateur a arrêté momentanément
d'utiliser la machine (pour répondre au téléphone par exemple), et
qu'il est donc préférable de baisser fortement la fréquence, quitte à
risquer une charge trop importante pour le processeur.

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

On a donc clairement pas les mêmes comportements ;-)

Merci pour ce message

De rien.

Vous avez filtré cet utilisateur ! Consultez son message

Cyrille Szymanski devait dire quelque chose comme ceci :

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.

Ah vi, c'est pas bête ça.

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.

Si je me base sur ma propre utilisation, la charge monte
progressivement, puis arrivée à son maximum elle fait des creux, mais
rarement des bosses, et enfin elle redescend plus brusquement qu'elle
n'était montée.
En fait graph ça donnerait quelque chose comme ça (je fait un palier
plat pour simplifier) :
____
/ |
/ |

Reporté sur l'utilisation à long terme, chez moi ça donne quelque
chose comme :

______
/ |
___/|____/|___/ |________/|___/|________
/ |
^^ ^^ ^^ ^^ ^^ ^^ ^^
^^ ^^ ^^ monté en charge ^^ ^^ arrêt de la machine
^^ ^^ ^^ ^^ ^^
^^ Piques dû par exemple à cron /
^^
Charge initiale de la machine

Evidement, la courbe est ici symbolique, dans la réalité elle est
moins lisse que cela.

Pour la suite, je pars du principe qu'une fréquence un peu trop élevée
est préférable à une charge trop importante.

Déjà, la première chose que je constate, c'est qu'il y a des montées
en charge qui sont prévisibles. Pourquoi ne pas tout simplement parser
au démarrage de powerd les fichiers comme la crontab ? S'il y a un
évènement prévu pour par exemple 1h05, on sait dès le début que la
charge va monter à ce moment là.
De même, il y a des montées en charge prévisibles, comme par exemple
lorsque ntpd interroge un serveur NTP pour vérifier que la machine est
toujours à l'heure. Je vois deux moyens pour prévoir ces montées en
charge.
La première est la plus simple, mais la plus limitative, elle consiste
à procéder comme pour la crontab, une analyse des fichiers de
configuration des démons succeptibles de la provoquer. Simple parce
qu'elle ne demande aucun algorythme compliqué, mais limitative
puisqu'il faut suivre l'évolution des programmes pour s'adapter aux
changements dans le fichier de configuration et qu'il faut tenir compte
de tous les programmes succeptibles d'agir de cette façon, même les
scripts à la noix (j'ai trois démons perl qui tourne chez moi).
La seconde méthode pour prévoir ces montées en charge est d'étudier le
comportement de la machine, pour s'apercevoir que la charge augmente à
intervale régulier et qu'elle augmente sensiblement de la même valeur à
chaque fois.
Ces montées en charge étant prévisibles, rien n'empèche (si ce n'est
peut-être la compléxité des algorythmes pour gérer cette prédictivité)
powerd d'agir en augmentant la fréquence juste avant qu'elles
n'interviennent.

La seconde chose que je constate, c'est que, lors des taches non
prédictibles, la montée en charge est sensiblement constante, la charge
maximum est rarement dépassée, et la baisse de charge est relativement
brutale. Etant du genre paranoïaque, j'aurais personnellement tendance
à me placer toujours en avance par rapport à l'avenir.
La montée en charge peut-être observée en comparant les x dernières
mesures (x < x1 < x2 ... < xn).
Si la charge n'est pas arrivée à son palier, la charge suivante
tournera autour de x + ( ( x1 + x2 ... + xn ) / n ).
Si la charge est arrivée à son palier, la charge suivante ne sera pas
supérieure à x, mais elle ne sera pas très inférieur non plus. Prévoir
une charge de x + ( ( x1 + x2 ... + xn ) / n ) serait superflu, mais en
offrant potentiellement une fréquence supérieur cela limiterait la
dégradation des performances tout en assurant que la charge du
processeur restera raisonnable.
Même chose si ce n'était qu'un pique et que la charge suivante baisse
sensiblement.

La baisse de charge est, d'après ce que moi j'ai constaté, plus facile
encore à observée. La différence entre x et x1 étant plus importante, n
peut être plus petit. Dans un tel cas, j'aurais tendance à considérer
que la charge sera égale à x, pour les mêmes raison qu'au-dessus.

Le vrai problème, c'est le palier. La charge diminue parfois, mais ne
dépasse que rarement son maximum. Là, et bien en ce moment je suis
entrain d'écouter de la musique, et j'ai la réponse sous les yeux,
c'est la représentation en barre du spectre de la musique. Il y a un
petit trait qui indique le niveau maximum atteint par chaque barre,
trait qui monte en suivant la barre, mais qui reste un instant à son
niveau maximum lorsque la barre descend.
Rapporté à powerd, ça donnerait quelque chose comme : Tant que la
charge est supérieure à la charge moyenne constatée et qu'elle est
supérieur à 90% (à définir) de la charge précédente, considérer que
l'on est toujours sur le palier et que la charge va remonter dans un
instant.

En fait, ce qui découle de tout ça, c'est que, amtha, l'algorythme ne
doit pas simplement tenir compte de l'état précédent, mais arriver à
définir, au fil du temps, un profil de la machine. Trouver les piques
récurents pour les prévenir, et déterminer quelle est la charge moyenne
lorsque l'utilisateur ne fait rien de particulier (comprendre "rien de
plus que d'habitude"). Ou plus exactement entre quelles limites (basse
et haute) se situe cette charge moyenne, puisqu'elle varie, mais a
tendance à rester confinée entre deux valeurs qu'elle ne dépasse jamais
si aucun évènement imprévu n'intervient.

Grace à cette double limite, il devient possible de déterminer qu'il y
a une montée en charge qui risque d'être importante, parce que la
charge est de 20% (à définir aussi) supérieur à la limite haute. A
l'inverse, si la charge descend sensiblement en dessous de la limite
basse, il y a fort à parier que l'utilisateur a arrêté momentanément
d'utiliser la machine (pour répondre au téléphone par exemple), et
qu'il est donc préférable de baisser fortement la fréquence, quitte à
risquer une charge trop importante pour le processeur.

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

On a donc clairement pas les mêmes comportements ;-)

Merci pour ce message

De rien.

Stephane Catteau

15/01/2007 à 17:26

Ducrot Bruno devait dire quelque chose comme ceci :

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.

Ca depend de la carte mere. Certaines, des vieilles surtout, a base de
chipset nforce ne le supportent pas. Pour d'autres, il s'agit
d'une option BIOS a ne pas oublier d'activer.
Enfin, certains vieux opterons ne le supportent pas.

Je verrais ça à l'usage. J'ai déjà passé la nuit du 1er à remettre
d'équère un serveur, je vais y aller à petits pas pour powerd ;)

Stephane Catteau

15/01/2007 à 17:27

Ducrot Bruno devait dire quelque chose comme ceci :

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 ?

Ca depend a la fois du processeur et des pilotes charges.
[snip]

Merci, archivé.

Eric Masson

15/01/2007 à 19:59

Ducrot Bruno writes:

'Lut,

A priori il manque 1600 et 800Mhz.

Ok.

Il y a peut-etre une option BIOS a activer, voire dans certain
cas, un bios a upgrader.

Pas d'option dans le bios, et le changelog du bios ne fait pas état de
l'ajout de ce genre d'option. Il faut que j'upgrade la machine, mais
pour cela il faut que je trouve un lecteur CD à lui brancher...

Si le coup de l'option BIOS ne marche pas, pourriez-vous m'envoyer
en prive (remplacez echo.fr par poupinou.org, et si possible ducrot
par bruno) la sortie de
acpidump -d -t

Ok, ça part.

Je verrai ce que je peux faire.

Merci d'avance, pour info la carte est une Abit KV8, équipée d'un
chipset VIA K8T800, je sais, ça date ;)

--

pourkoi faire ca c koi le but? je vois pas l interet c un forum libre
ou tt le monde px s exprimer c pas mtnt kil faut reagir c ds les posts
Au secours, mon ROT-13 ne marche plus :-((((

-+- PC in <http://www.le-gnu.net> : Neuneu decode à plein tube -+-

Cyrille Szymanski

16/01/2007 à 00:38

Patrick Lamaizière wrote in
news::

Merci, je me disais bien que j'avais raté un truc. Quelle idée de mettre
ça en "debug" aussi.

Pour info, ce sysctl existe principalement pour interdire les fréquences
trop basses qui font planter certaines machines (probablement à cause d'une
mauvaise détection des vitesses réellement autorisées, mais là je m'avance
un peu). Voilà pourquoi il est dans debug.

C'est vrai qu'il manque min/max à powerd, mais comme il a été discuté sur
acpi@, la meilleure place pour ce genre de paramètre c'est probablement
dans un fichier de config et pas une option de plus sur la ligne de
commande. Cela dit, en ligne de commande c'est mieux que rien (un tiens
vaut mieux que deux tu l'auras, gnagnagna).

--
Cyrille Szymanski

Jérémy JUST

16/01/2007 à 00:59

Le Sat, 13 Jan 2007 21:33:55 +0100,

En ayant un peu marre de voir la facture d'électricité augmenter à
chaque fois que je la reçois [...] j'ai fouillé un peu pour trouver
une solution. La meilleure que j'ai trouvée, c'est powerd.

Tu as eu plein d'intéressants retours concernant la configuration
logicielle, mais j'aimerais avoir une ordre de grandeur de l'efficacité
des solutions proposées.

Est-ce que quelqu'un aurait à la fois un ordinateur configuré
correctement concernant l'économie d'énergie et un watt-mètre? Est-ce
que l'économie globale est réellement notable pour un petit serveur?
Sur ma machine (Linux sans économie d'énergie), la différence entre
le repos et la pleine charge est déjà de 40W par processeur. Si réduire
le fréquence ne fait gagner que quelques watts, ça me semble
négligeable.

Au passage, il faut remarquer que l'énergie « consommée » par tes
machines n'est pas perdue, puisque tu peux la déduire de l'énergie que
devra fournir ton chauffage (en hiver).

--
Jérémy JUST

Cyrille Szymanski

16/01/2007 à 08:36

Stephane Catteau wrote in
news::

Reporté sur l'utilisation à long terme, chez moi ça donne quelque
chose comme :

______
/ |
___/|____/|___/ |________/|___/|________
/ |
^^ ^^ ^^ ^^ ^^ ^^ ^^
^^ ^^ ^^ monté en charge ^^ ^^ arrêt de la machine
^^ ^^ ^^ ^^ ^^
^^ Piques dû par exemple à cron /
^^
Charge initiale de la machine

Evidement, la courbe est ici symbolique, dans la réalité elle est
moins lisse que cela.

A cette échelle de temps, peu importe l'algorithme implémenté tu auras
l'impression que la vitesse du CPU suit exactement la charge qui lui est
imposée. A peu près tous les algos que j'ai vus vont mettre le CPU à la
vitesse minimale en quelques échantillons s'il ne fait rien, et maximale
s'il est occupé. A mon avis le problème est d'optimiser sur des intervalles
de l'ordre de deux ou trois secondes.

Si on trouve une bonne approche, alors tous les phénomènes plus lents
seront eux aussi traités efficacement.

Pourquoi ne pas tout simplement parser au démarrage de powerd les
fichiers comme la crontab ? S'il y a un évènement prévu pour par exemple
1h05, on sait dès le début que la charge va monter à ce moment là.

Oui, un des projets pour powerd évoqué sur acpi@ est d'utiliser un fichier
de config au lieu d'options en ligne de commande. Il serait tout à fait
possible de définir des profils dépendant du temps (de la plage horaire)
mais aussi de l'état batterie/secteur, ou encore du pourcentage de batterie
restante etc.

La montée en charge peut-être observée en comparant les x dernières
mesures (x < x1 < x2 ... < xn).
Si la charge n'est pas arrivée à son palier, la charge suivante
tournera autour de x + ( ( x1 + x2 ... + xn ) / n ).

En gros le filtrage que tu proposes est une moyenne des n échantillons
précédents plus un petit quelquechose (marge de sécurité). Je suis d'accord
avec ça, c'est ce qui est sous entendu quand on dit que la charge future
est prédite égale à la charge passée. Le tout est de bien choisir la valeur
de n... car de grandes valeurs introduisent un retard et pour n=1 cela
revient à prendre la valeur précédemment observée (qui n'est probablement
pas assez lissée).

--
Cyrille Szymanski

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

Reporté sur l'utilisation à long terme, chez moi ça donne quelque
chose comme :

______
/ |
___/|____/|___/ |________/|___/|________
/ |
^^ ^^ ^^ ^^ ^^ ^^ ^^
^^ ^^ ^^ monté en charge ^^ ^^ arrêt de la machine
^^ ^^ ^^ ^^ ^^
^^ Piques dû par exemple à cron /
^^
Charge initiale de la machine

Evidement, la courbe est ici symbolique, dans la réalité elle est
moins lisse que cela.

A cette échelle de temps, peu importe l'algorithme implémenté tu auras
l'impression que la vitesse du CPU suit exactement la charge qui lui est
imposée. A peu près tous les algos que j'ai vus vont mettre le CPU à la
vitesse minimale en quelques échantillons s'il ne fait rien, et maximale
s'il est occupé. A mon avis le problème est d'optimiser sur des intervalles
de l'ordre de deux ou trois secondes.

Si on trouve une bonne approche, alors tous les phénomènes plus lents
seront eux aussi traités efficacement.

Pourquoi ne pas tout simplement parser au démarrage de powerd les
fichiers comme la crontab ? S'il y a un évènement prévu pour par exemple
1h05, on sait dès le début que la charge va monter à ce moment là.

Oui, un des projets pour powerd évoqué sur acpi@ est d'utiliser un fichier
de config au lieu d'options en ligne de commande. Il serait tout à fait
possible de définir des profils dépendant du temps (de la plage horaire)
mais aussi de l'état batterie/secteur, ou encore du pourcentage de batterie
restante etc.

La montée en charge peut-être observée en comparant les x dernières
mesures (x < x1 < x2 ... < xn).
Si la charge n'est pas arrivée à son palier, la charge suivante
tournera autour de x + ( ( x1 + x2 ... + xn ) / n ).

En gros le filtrage que tu proposes est une moyenne des n échantillons
précédents plus un petit quelquechose (marge de sécurité). Je suis d'accord
avec ça, c'est ce qui est sous entendu quand on dit que la charge future
est prédite égale à la charge passée. Le tout est de bien choisir la valeur
de n... car de grandes valeurs introduisent un retard et pour n=1 cela
revient à prendre la valeur précédemment observée (qui n'est probablement
pas assez lissée).

--
Cyrille Szymanski

Vous avez filtré cet utilisateur ! Consultez son message

Stephane Catteau wrote in
news::

Reporté sur l'utilisation à long terme, chez moi ça donne quelque
chose comme :

______
/ |
___/|____/|___/ |________/|___/|________
/ |
^^ ^^ ^^ ^^ ^^ ^^ ^^
^^ ^^ ^^ monté en charge ^^ ^^ arrêt de la machine
^^ ^^ ^^ ^^ ^^
^^ Piques dû par exemple à cron /
^^
Charge initiale de la machine

Evidement, la courbe est ici symbolique, dans la réalité elle est
moins lisse que cela.

A cette échelle de temps, peu importe l'algorithme implémenté tu auras
l'impression que la vitesse du CPU suit exactement la charge qui lui est
imposée. A peu près tous les algos que j'ai vus vont mettre le CPU à la
vitesse minimale en quelques échantillons s'il ne fait rien, et maximale
s'il est occupé. A mon avis le problème est d'optimiser sur des intervalles
de l'ordre de deux ou trois secondes.

Si on trouve une bonne approche, alors tous les phénomènes plus lents
seront eux aussi traités efficacement.

Pourquoi ne pas tout simplement parser au démarrage de powerd les
fichiers comme la crontab ? S'il y a un évènement prévu pour par exemple
1h05, on sait dès le début que la charge va monter à ce moment là.

Oui, un des projets pour powerd évoqué sur acpi@ est d'utiliser un fichier
de config au lieu d'options en ligne de commande. Il serait tout à fait
possible de définir des profils dépendant du temps (de la plage horaire)
mais aussi de l'état batterie/secteur, ou encore du pourcentage de batterie
restante etc.

La montée en charge peut-être observée en comparant les x dernières
mesures (x < x1 < x2 ... < xn).
Si la charge n'est pas arrivée à son palier, la charge suivante
tournera autour de x + ( ( x1 + x2 ... + xn ) / n ).

En gros le filtrage que tu proposes est une moyenne des n échantillons
précédents plus un petit quelquechose (marge de sécurité). Je suis d'accord
avec ça, c'est ce qui est sous entendu quand on dit que la charge future
est prédite égale à la charge passée. Le tout est de bien choisir la valeur
de n... car de grandes valeurs introduisent un retard et pour n=1 cela
revient à prendre la valeur précédemment observée (qui n'est probablement
pas assez lissée).

--
Cyrille Szymanski

patpro ~ Patrick Proniewski

16/01/2007 à 09:52

In article ,
Cyrille Szymanski wrote:

Stephane Catteau wrote in
news::

Reporté sur l'utilisation à long terme, chez moi ça donne quelque
chose comme :

______
/ |
___/|____/|___/ |________/|___/|________
/ |
^^ ^^ ^^ ^^ ^^ ^^ ^^
^^ ^^ ^^ monté en charge ^^ ^^ arrêt de la machine
^^ ^^ ^^ ^^ ^^
^^ Piques dû par exemple à cron /
^^
Charge initiale de la machine

Evidement, la courbe est ici symbolique, dans la réalité elle est
moins lisse que cela.

A cette échelle de temps, peu importe l'algorithme implémenté tu auras
l'impression que la vitesse du CPU suit exactement la charge qui lui est
imposée. A peu près tous les algos que j'ai vus vont mettre le CPU à la
vitesse minimale en quelques échantillons s'il ne fait rien, et maximale
s'il est occupé. A mon avis le problème est d'optimiser sur des intervalles
de l'ordre de deux ou trois secondes.

J'ai fait un échantillonnage crado sur un peu moins de 40h :

les données en txt :
<http://patpro.net/~patpro/date_freq> un point toutes les 2 secondes.

le graph résultant :
<http://patpro.net/~patpro/frequence2.png>

On voit un pic tous les 1/4 d'heure, correspondant à une crontab rrdtool
qui génère des graph. Le pic double vers 20h au début du graph
correspond à un make buildworld suivit d'un make buildkernel et des make
install subséquent.
La machine sert de passerelle internet et de petit serveur web.

patpro

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

Ducrot Bruno

16/01/2007 à 11:31

On Mon, 15 Jan 2007 19:59:10 +0100, Eric Masson wrote:

Ducrot Bruno writes:

'Lut,

A priori il manque 1600 et 800Mhz.

Ok.

Il y a peut-etre une option BIOS a activer, voire dans certain
cas, un bios a upgrader.

Pas d'option dans le bios, et le changelog du bios ne fait pas état de
l'ajout de ce genre d'option. Il faut que j'upgrade la machine, mais
pour cela il faut que je trouve un lecteur CD à lui brancher...

Si le coup de l'option BIOS ne marche pas, pourriez-vous m'envoyer
en prive (remplacez echo.fr par poupinou.org, et si possible ducrot
par bruno) la sortie de
acpidump -d -t

Ok, ça part.

Je verrai ce que je peux faire.

Merci d'avance, pour info la carte est une Abit KV8, équipée d'un
chipset VIA K8T800, je sais, ça date ;)

J'ai une abit KV8-MAX3, et j'ai bien une option a active, dans
Power management - Setup / Cool'n'Quiet Technology
qui correspond justement a ce que l'on veut. Etes vous certain
que ce n'est pas le cas chez vous, avant que je ne modifie votre
table ?

--
Bruno Ducrot

-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.

[FreeBSD] powerd est-il si interessant ?

10 réponses

Veuillez sélectionner un problème