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 ?
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.
Effectivement, et elle est bien sur "Enable".
Etes vous certain que ce n'est pas le cas chez vous, avant que je ne modifie votre table ?
Je vais passer l'upgrade de bios ce midi, selon changelog, rien ne devrait évoluer mais bon, autant attendre de savoir.
Encore merci
-- PR> tu es en avance d'un an pour le nouveau millénaire il me semble que (2000) est bien le nouveau millenaire justement par contre on change de siecle l'annee prochaine en 2001 -+- kiboot in http://www.le-gnu.net : Émile énerve pour l'an d'Émile.
Ducrot Bruno <ducrot@echo.fr> writes:
'Lut,
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.
Effectivement, et elle est bien sur "Enable".
Etes vous certain que ce n'est pas le cas chez vous, avant que je ne
modifie votre table ?
Je vais passer l'upgrade de bios ce midi, selon changelog, rien ne
devrait évoluer mais bon, autant attendre de savoir.
Encore merci
--
PR> tu es en avance d'un an pour le nouveau millénaire
il me semble que (2000) est bien le nouveau millenaire justement
par contre on change de siecle l'annee prochaine en 2001
-+- kiboot in http://www.le-gnu.net : Émile énerve pour l'an d'Émile.
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.
Effectivement, et elle est bien sur "Enable".
Etes vous certain que ce n'est pas le cas chez vous, avant que je ne modifie votre table ?
Je vais passer l'upgrade de bios ce midi, selon changelog, rien ne devrait évoluer mais bon, autant attendre de savoir.
Encore merci
-- PR> tu es en avance d'un an pour le nouveau millénaire il me semble que (2000) est bien le nouveau millenaire justement par contre on change de siecle l'annee prochaine en 2001 -+- kiboot in http://www.le-gnu.net : Émile énerve pour l'an d'Émile.
Eric Masson
Eric Masson writes:
'Lut,
Je vais passer l'upgrade de bios ce midi, selon changelog, rien ne devrait évoluer mais bon, autant attendre de savoir.
Bon, ça a évolué, j'ai maintenant une fréquence supplémentaire : dev.cpu.0.freq_levels: 1836/89000 1020/22000
Mais alors, le reste est une véritable catastrophe, la machine ne boote qu'après que la cmos ait été nettoyée par le jumper idoine, dans tous les autres cas, elle bloque avec un post code 26 (il semble que ce soit lié à la carte graphique...)
Donc, downgrade en révision 23 et enfin retour à la 21 si nécessaire, donc un peu de taf en perspective ;)
-- LC> A la différence de certains, je lis les articles. C'est tout. Oui, on sait. Bientôt, les noms, puis les adjectifs, puis les verbes. Avec un peu de patience, dans quelques années, une phrase entière. -+- LW in <www.le-gnu.net> : Moi-je nous fait l'article-+-
Eric Masson <emss@free.fr> writes:
'Lut,
Je vais passer l'upgrade de bios ce midi, selon changelog, rien ne
devrait évoluer mais bon, autant attendre de savoir.
Bon, ça a évolué, j'ai maintenant une fréquence supplémentaire :
dev.cpu.0.freq_levels: 1836/89000 1020/22000
Mais alors, le reste est une véritable catastrophe, la machine ne boote
qu'après que la cmos ait été nettoyée par le jumper idoine, dans tous
les autres cas, elle bloque avec un post code 26 (il semble que ce soit
lié à la carte graphique...)
Donc, downgrade en révision 23 et enfin retour à la 21 si nécessaire,
donc un peu de taf en perspective ;)
--
LC> A la différence de certains, je lis les articles. C'est tout.
Oui, on sait. Bientôt, les noms, puis les adjectifs, puis les verbes.
Avec un peu de patience, dans quelques années, une phrase entière.
-+- LW in <www.le-gnu.net> : Moi-je nous fait l'article-+-
Je vais passer l'upgrade de bios ce midi, selon changelog, rien ne devrait évoluer mais bon, autant attendre de savoir.
Bon, ça a évolué, j'ai maintenant une fréquence supplémentaire : dev.cpu.0.freq_levels: 1836/89000 1020/22000
Mais alors, le reste est une véritable catastrophe, la machine ne boote qu'après que la cmos ait été nettoyée par le jumper idoine, dans tous les autres cas, elle bloque avec un post code 26 (il semble que ce soit lié à la carte graphique...)
Donc, downgrade en révision 23 et enfin retour à la 21 si nécessaire, donc un peu de taf en perspective ;)
-- LC> A la différence de certains, je lis les articles. C'est tout. Oui, on sait. Bientôt, les noms, puis les adjectifs, puis les verbes. Avec un peu de patience, dans quelques années, une phrase entière. -+- LW in <www.le-gnu.net> : Moi-je nous fait l'article-+-
Ducrot Bruno
On Tue, 16 Jan 2007 14:50:38 +0100, Eric Masson wrote:
Eric Masson writes:
'Lut,
Je vais passer l'upgrade de bios ce midi, selon changelog, rien ne devrait évoluer mais bon, autant attendre de savoir.
Bon, ça a évolué, j'ai maintenant une fréquence supplémentaire : dev.cpu.0.freq_levels: 1836/89000 1020/22000
Rha zut, je me suis trompe de revision pour le processeur. Ne pas appliquer le patch que je vous ai envoye tout a l'heure.
Mais alors, le reste est une véritable catastrophe, la machine ne boote qu'après que la cmos ait été nettoyée par le jumper idoine, dans tous les autres cas, elle bloque avec un post code 26 (il semble que ce soit lié à la carte graphique...)
Donc, downgrade en révision 23 et enfin retour à la 21 si nécessaire, donc un peu de taf en perspective ;)
Bon courage !
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On Tue, 16 Jan 2007 14:50:38 +0100, Eric Masson <emss@free.fr> wrote:
Eric Masson <emss@free.fr> writes:
'Lut,
Je vais passer l'upgrade de bios ce midi, selon changelog, rien ne
devrait évoluer mais bon, autant attendre de savoir.
Bon, ça a évolué, j'ai maintenant une fréquence supplémentaire :
dev.cpu.0.freq_levels: 1836/89000 1020/22000
Rha zut, je me suis trompe de revision pour le processeur.
Ne pas appliquer le patch que je vous ai envoye tout a l'heure.
Mais alors, le reste est une véritable catastrophe, la machine ne boote
qu'après que la cmos ait été nettoyée par le jumper idoine, dans tous
les autres cas, elle bloque avec un post code 26 (il semble que ce soit
lié à la carte graphique...)
Donc, downgrade en révision 23 et enfin retour à la 21 si nécessaire,
donc un peu de taf en perspective ;)
Bon courage !
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
On Tue, 16 Jan 2007 14:50:38 +0100, Eric Masson wrote:
Eric Masson writes:
'Lut,
Je vais passer l'upgrade de bios ce midi, selon changelog, rien ne devrait évoluer mais bon, autant attendre de savoir.
Bon, ça a évolué, j'ai maintenant une fréquence supplémentaire : dev.cpu.0.freq_levels: 1836/89000 1020/22000
Rha zut, je me suis trompe de revision pour le processeur. Ne pas appliquer le patch que je vous ai envoye tout a l'heure.
Mais alors, le reste est une véritable catastrophe, la machine ne boote qu'après que la cmos ait été nettoyée par le jumper idoine, dans tous les autres cas, elle bloque avec un post code 26 (il semble que ce soit lié à la carte graphique...)
Donc, downgrade en révision 23 et enfin retour à la 21 si nécessaire, donc un peu de taf en perspective ;)
Bon courage !
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Ducrot Bruno
On Tue, 16 Jan 2007 00:59:44 +0100, Jérémy JUST wrote:
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).
Sur 10 serveurs bi-opterons sous linux, avec 3 disques durs, il y a un gain espere d'environ 15% si je me souviens bien.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On Tue, 16 Jan 2007 00:59:44 +0100, Jérémy JUST
<jeremy_just@netcourrier.com> wrote:
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).
Sur 10 serveurs bi-opterons sous linux, avec 3 disques durs, il y a
un gain espere d'environ 15% si je me souviens bien.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
On Tue, 16 Jan 2007 00:59:44 +0100, Jérémy JUST wrote:
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).
Sur 10 serveurs bi-opterons sous linux, avec 3 disques durs, il y a un gain espere d'environ 15% si je me souviens bien.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Stephane Catteau
Cyrille Szymanski devait dire quelque chose comme ceci :
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.
D'où, amha, l'importance d'arriver à anticiper les montées en charge prévisibles (cron et compagnie). Un utilisateur lance soit une application vraiment gourmande, qu'il l'utilisera alors pendant plusieurs minutes, auquel cas le modèle actuel répond assez bien à ce comportement. Soit il exécute de petites commandes qui la plus part du temps seront terminées avant d'avoir été détectées (ls, cat, etc.). Les démons par contre lancent des programmes/scripts qui agissent le plus rapidement possible et font un maximum de choses durant ce faible interval. En arrivant à isoler les évènements récurents, et donc à les prévoir, powerd s'approchera encore un peu plus, il me semble, du fonctionnement optimisé que tu recherches, puisqu'il sera en mesure de traiter par anticipation une partie de ces intervalles de deux, trois, secondes.
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).
La descente est toujours plus rapide que la montée, il faut donc que n soit le plus petit possible pour avoir un résultat optimisé. A l'inverse, la montée en charge est plus progressive, donc n doit être plus important. Reste à trouver le moyen de déterminer la nature de la courbe, pour savoir si l'on est en montée ou en descente, voire si l'on est en palier. Un banal x > x1 n'aiderait pas, même dans les phases de montée et de descente il y a des piques et des creux. Ca ne ferait donc que repousser le problème, puisqu'il faudrait comparer x > x1 > ... > xn, avec n qui doit varier selon la nature de la courbe. Donc amha, il faudrait travailler avec deux courbes de mesures. La première qui résulterait d'un lissage des mesures, pour déterminer la nature de la courbe, et donc la valeur de n, et la seconde qui correspondrait aux valeurs réellement constatées, et qui servirait à prédire la charge suivante. Et c'est là que mes maths déplorables me rattrape, je n'ai aucune idée de la façon dont ça pourrait se faire ;)
Cyrille Szymanski devait dire quelque chose comme ceci :
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.
D'où, amha, l'importance d'arriver à anticiper les montées en charge
prévisibles (cron et compagnie). Un utilisateur lance soit une
application vraiment gourmande, qu'il l'utilisera alors pendant
plusieurs minutes, auquel cas le modèle actuel répond assez bien à ce
comportement. Soit il exécute de petites commandes qui la plus part du
temps seront terminées avant d'avoir été détectées (ls, cat, etc.).
Les démons par contre lancent des programmes/scripts qui agissent le
plus rapidement possible et font un maximum de choses durant ce faible
interval. En arrivant à isoler les évènements récurents, et donc à les
prévoir, powerd s'approchera encore un peu plus, il me semble, du
fonctionnement optimisé que tu recherches, puisqu'il sera en mesure de
traiter par anticipation une partie de ces intervalles de deux, trois,
secondes.
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).
La descente est toujours plus rapide que la montée, il faut donc que n
soit le plus petit possible pour avoir un résultat optimisé. A
l'inverse, la montée en charge est plus progressive, donc n doit être
plus important. Reste à trouver le moyen de déterminer la nature de la
courbe, pour savoir si l'on est en montée ou en descente, voire si l'on
est en palier. Un banal x > x1 n'aiderait pas, même dans les phases de
montée et de descente il y a des piques et des creux. Ca ne ferait donc
que repousser le problème, puisqu'il faudrait comparer x > x1 > ... >
xn, avec n qui doit varier selon la nature de la courbe.
Donc amha, il faudrait travailler avec deux courbes de mesures. La
première qui résulterait d'un lissage des mesures, pour déterminer la
nature de la courbe, et donc la valeur de n, et la seconde qui
correspondrait aux valeurs réellement constatées, et qui servirait à
prédire la charge suivante. Et c'est là que mes maths déplorables me
rattrape, je n'ai aucune idée de la façon dont ça pourrait se faire ;)
Cyrille Szymanski devait dire quelque chose comme ceci :
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.
D'où, amha, l'importance d'arriver à anticiper les montées en charge prévisibles (cron et compagnie). Un utilisateur lance soit une application vraiment gourmande, qu'il l'utilisera alors pendant plusieurs minutes, auquel cas le modèle actuel répond assez bien à ce comportement. Soit il exécute de petites commandes qui la plus part du temps seront terminées avant d'avoir été détectées (ls, cat, etc.). Les démons par contre lancent des programmes/scripts qui agissent le plus rapidement possible et font un maximum de choses durant ce faible interval. En arrivant à isoler les évènements récurents, et donc à les prévoir, powerd s'approchera encore un peu plus, il me semble, du fonctionnement optimisé que tu recherches, puisqu'il sera en mesure de traiter par anticipation une partie de ces intervalles de deux, trois, secondes.
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).
La descente est toujours plus rapide que la montée, il faut donc que n soit le plus petit possible pour avoir un résultat optimisé. A l'inverse, la montée en charge est plus progressive, donc n doit être plus important. Reste à trouver le moyen de déterminer la nature de la courbe, pour savoir si l'on est en montée ou en descente, voire si l'on est en palier. Un banal x > x1 n'aiderait pas, même dans les phases de montée et de descente il y a des piques et des creux. Ca ne ferait donc que repousser le problème, puisqu'il faudrait comparer x > x1 > ... > xn, avec n qui doit varier selon la nature de la courbe. Donc amha, il faudrait travailler avec deux courbes de mesures. La première qui résulterait d'un lissage des mesures, pour déterminer la nature de la courbe, et donc la valeur de n, et la seconde qui correspondrait aux valeurs réellement constatées, et qui servirait à prédire la charge suivante. Et c'est là que mes maths déplorables me rattrape, je n'ai aucune idée de la façon dont ça pourrait se faire ;)
Stephane Catteau
patpro ~ Patrick Proniewski n'était pas loin de dire :
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.
En fait, le plus dur pour arriver à trouver les montées en charge prédictible, comme le pic qui survient tous les quatr d'heure, c'est qu'elles sont parfois cachées derrière une montée en charge dû à autre chose, zut !
patpro ~ Patrick Proniewski n'était pas loin de dire :
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.
En fait, le plus dur pour arriver à trouver les montées en charge
prédictible, comme le pic qui survient tous les quatr d'heure, c'est
qu'elles sont parfois cachées derrière une montée en charge dû à autre
chose, zut !
patpro ~ Patrick Proniewski n'était pas loin de dire :
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.
En fait, le plus dur pour arriver à trouver les montées en charge prédictible, comme le pic qui survient tous les quatr d'heure, c'est qu'elles sont parfois cachées derrière une montée en charge dû à autre chose, zut !
