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 ?
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é.
héhé, pas grave, merci en tout cas. J'ai fait suivre sur la ML acpi de freebsd mon probleme de reconnaissance de processeur par le driver EST de cpufreq, affaire à suivre.
patpro
-- http://www.patpro.net/
In article <iobs74-dpm.ln1@srvbsdnanssv.oursoides-associes.com>,
Eric Masson <emss@free.fr> wrote:
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é.
héhé, pas grave, merci en tout cas.
J'ai fait suivre sur la ML acpi de freebsd mon probleme de
reconnaissance de processeur par le driver EST de cpufreq, affaire à
suivre.
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é.
héhé, pas grave, merci en tout cas. J'ai fait suivre sur la ML acpi de freebsd mon probleme de reconnaissance de processeur par le driver EST de cpufreq, affaire à suivre.
patpro
-- http://www.patpro.net/
Ducrot Bruno
On 14 Jan 2007 18:47:18 GMT, Cyrille Szymanski wrote:
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é.
Oui, tout a fait. J'ai d'ailleurs quelques trucs a tester et c'est assez marrant de voir que vous avez eu a peu-pres le meme genre de raisonnements. Je suis en train en fait d'ameliorer l'algo. PAST en ce sens. Si ca peut vous aider, je peux vous envoyer PAST mais brut de fonderie, avec l'assomption classique d'une charge processeur a 60% par defaut, celle-ci pouvant etre modifie mais uniquement en ligne de commande. Mais avant il faut que je rentre chez moi. Je suis au boulot, la...
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On 14 Jan 2007 18:47:18 GMT, Cyrille Szymanski <cns2@cns.invalid> wrote:
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é.
Oui, tout a fait. J'ai d'ailleurs quelques trucs a tester et c'est assez
marrant de voir que vous avez eu a peu-pres le meme genre de
raisonnements. Je suis en train en fait d'ameliorer l'algo. PAST en ce sens.
Si ca peut vous aider, je peux vous envoyer PAST mais brut de fonderie, avec
l'assomption classique d'une charge processeur a 60% par defaut, celle-ci
pouvant etre modifie mais uniquement en ligne de commande. Mais avant
il faut que je rentre chez moi. Je suis au boulot, la...
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
On 14 Jan 2007 18:47:18 GMT, Cyrille Szymanski wrote:
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é.
Oui, tout a fait. J'ai d'ailleurs quelques trucs a tester et c'est assez marrant de voir que vous avez eu a peu-pres le meme genre de raisonnements. Je suis en train en fait d'ameliorer l'algo. PAST en ce sens. Si ca peut vous aider, je peux vous envoyer PAST mais brut de fonderie, avec l'assomption classique d'une charge processeur a 60% par defaut, celle-ci pouvant etre modifie mais uniquement en ligne de commande. Mais avant il faut que je rentre chez moi. Je suis au boulot, la...
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Ducrot Bruno
On Sun, 14 Jan 2007 23:28:13 +0100, Patrick Lamaizière wrote:
Patrick Lamaizière :
Je n'ai pas trouvé pour mettre un seuil bas ou haut pour les valeurs de fréquences (un mini / maxi).
J'ai patché pour ajouter une fréquence min et une max en mode adaptive (pour la RELENG_6_2) -m minfreq -M maxfreq (l'en faudrait deux autres pour si on est sur batteries ou pas)
Le problème sinon c'est la réactivité, sans seuil mini ma machine descend à 75 MHz et ça le fait pas vraiment avec KDE et les applis intéractives. Là j'ai mis 800 MHz (sur secteur) ça suffit et il reste de la puissance en marge (peut monter jusqu'à 1600).
C'est pour ca qu'il y a un sysctl debug.cpufreq.lowest.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On Sun, 14 Jan 2007 23:28:13 +0100, Patrick Lamaizière <adresse@est.invalid>
wrote:
Patrick Lamaizière :
Je n'ai pas trouvé pour mettre un seuil bas ou haut pour les valeurs
de fréquences (un mini / maxi).
J'ai patché pour ajouter une fréquence min et une max en mode adaptive
(pour la RELENG_6_2)
-m minfreq -M maxfreq (l'en faudrait deux autres pour si on est sur
batteries ou pas)
Le problème sinon c'est la réactivité, sans seuil mini ma machine
descend à 75 MHz et ça le fait pas vraiment avec KDE et les applis
intéractives. Là j'ai mis 800 MHz (sur secteur) ça suffit et il reste
de la puissance en marge (peut monter jusqu'à 1600).
C'est pour ca qu'il y a un sysctl debug.cpufreq.lowest.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
On Sun, 14 Jan 2007 23:28:13 +0100, Patrick Lamaizière wrote:
Patrick Lamaizière :
Je n'ai pas trouvé pour mettre un seuil bas ou haut pour les valeurs de fréquences (un mini / maxi).
J'ai patché pour ajouter une fréquence min et une max en mode adaptive (pour la RELENG_6_2) -m minfreq -M maxfreq (l'en faudrait deux autres pour si on est sur batteries ou pas)
Le problème sinon c'est la réactivité, sans seuil mini ma machine descend à 75 MHz et ça le fait pas vraiment avec KDE et les applis intéractives. Là j'ai mis 800 MHz (sur secteur) ça suffit et il reste de la puissance en marge (peut monter jusqu'à 1600).
C'est pour ca qu'il y a un sysctl debug.cpufreq.lowest.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Ducrot Bruno
On Sun, 14 Jan 2007 15:55:36 +0100, Stephane Catteau wrote:
Eric Masson n'était pas loin de dire :
La meilleure que j'ai trouvée, c'est powerd. En mode adaptative, ça semble parfait pour limiter un peu la consommation, mais bon, est-ce que ça vaut vraiment le coup ?
Il faut que le cpu de ta machine le supporte, sur l'amd64 qui me sert de machine principale, le processeur ne supporte pas de changer de vitesse...
En théorie ils devraient tous supporter ça.
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.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On Sun, 14 Jan 2007 15:55:36 +0100, Stephane Catteau <steph.nospam@sc4x.net>
wrote:
Eric Masson n'était pas loin de dire :
La meilleure que j'ai trouvée, c'est powerd. En mode adaptative, ça
semble parfait pour limiter un peu la consommation, mais bon, est-ce
que ça vaut vraiment le coup ?
Il faut que le cpu de ta machine le supporte, sur l'amd64 qui me sert de
machine principale, le processeur ne supporte pas de changer de
vitesse...
En théorie ils devraient tous supporter ça.
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.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
On Sun, 14 Jan 2007 15:55:36 +0100, Stephane Catteau wrote:
Eric Masson n'était pas loin de dire :
La meilleure que j'ai trouvée, c'est powerd. En mode adaptative, ça semble parfait pour limiter un peu la consommation, mais bon, est-ce que ça vaut vraiment le coup ?
Il faut que le cpu de ta machine le supporte, sur l'amd64 qui me sert de machine principale, le processeur ne supporte pas de changer de vitesse...
En théorie ils devraient tous supporter ça.
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.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Ducrot Bruno
On Sat, 13 Jan 2007 21:33:55 +0100, Stephane Catteau wrote:
Bonjour,
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 ?
Ca depend a la fois du processeur et des pilotes charges. Par exemple, si devinfo vous donne quelque chose comme-ca :
cpu0 acpi_throttle0 cpufreq0
alors seul acpi_throttle0 va servir pour reduire la frequence du processeur. (en fait ce n'est meme pas vrai, au sens ou acpi_throttle ne changera jamais la frequence reelle du processeur). Celui-la en fait ne servira pas a grand chose pour reduire la puissance consommee car, en schematisant un peu, le voltage ne sera pas modifie.
La meme remarque s'applique pour p4tcc.
Tous les autres pilotes, par contre, change egalement le voltage du processeur, et c'est ca qui va reellement changer la donne lorsque l'on desire un veritable gain en consomation d'energie.
Enfin, le pilote cpufreq0 que l'on voit apparaitre dans la sortie de devinfo sert uniquement a faire un merge entre les autres pilotes et n'est pas, en tant que tel, un vrai pilote de peripheriques. Il sert surtout a creer les sysctl sous dev.cpu.?.
Il ne faut pas le confondre avec cpufreq.ko, qui est un bundle de differents pilotes comme powernow, est, p4tcc, etc.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On Sat, 13 Jan 2007 21:33:55 +0100, Stephane Catteau <steph.nospam@sc4x.net>
wrote:
Bonjour,
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 ?
Ca depend a la fois du processeur et des pilotes charges.
Par exemple, si devinfo vous donne quelque chose comme-ca :
cpu0
acpi_throttle0
cpufreq0
alors seul acpi_throttle0 va servir pour reduire la frequence du processeur.
(en fait ce n'est meme pas vrai, au sens ou acpi_throttle ne changera jamais
la frequence reelle du processeur).
Celui-la en fait ne servira pas a grand chose pour reduire la puissance
consommee car, en schematisant un peu, le voltage ne sera pas modifie.
La meme remarque s'applique pour p4tcc.
Tous les autres pilotes, par contre, change egalement le voltage du processeur,
et c'est ca qui va reellement changer la donne lorsque l'on desire un veritable
gain en consomation d'energie.
Enfin, le pilote cpufreq0 que l'on voit apparaitre dans la sortie de devinfo
sert uniquement a faire un merge entre les autres pilotes et n'est pas, en
tant que tel, un vrai pilote de peripheriques. Il sert surtout a creer
les sysctl sous dev.cpu.?.
Il ne faut pas le confondre avec cpufreq.ko, qui est un bundle
de differents pilotes comme powernow, est, p4tcc, etc.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
On Sat, 13 Jan 2007 21:33:55 +0100, Stephane Catteau wrote:
Bonjour,
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 ?
Ca depend a la fois du processeur et des pilotes charges. Par exemple, si devinfo vous donne quelque chose comme-ca :
cpu0 acpi_throttle0 cpufreq0
alors seul acpi_throttle0 va servir pour reduire la frequence du processeur. (en fait ce n'est meme pas vrai, au sens ou acpi_throttle ne changera jamais la frequence reelle du processeur). Celui-la en fait ne servira pas a grand chose pour reduire la puissance consommee car, en schematisant un peu, le voltage ne sera pas modifie.
La meme remarque s'applique pour p4tcc.
Tous les autres pilotes, par contre, change egalement le voltage du processeur, et c'est ca qui va reellement changer la donne lorsque l'on desire un veritable gain en consomation d'energie.
Enfin, le pilote cpufreq0 que l'on voit apparaitre dans la sortie de devinfo sert uniquement a faire un merge entre les autres pilotes et n'est pas, en tant que tel, un vrai pilote de peripheriques. Il sert surtout a creer les sysctl sous dev.cpu.?.
Il ne faut pas le confondre avec cpufreq.ko, qui est un bundle de differents pilotes comme powernow, est, p4tcc, etc.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Ducrot Bruno
On Sun, 14 Jan 2007 12:57:47 +0100, Patrick Lamaizière wrote:
patpro ~ patrick proniewski :
Ais-je besoin de charger explicitement cpufreq.ko, ou est ce que acpi.ko qui est déjà chargé est suffisant ?
powerd marche out-of-the-box
Ben oui. Je me demande à quoi sert le module cpufreq.ko alors ?
C'est un bundle de differents pilotes. Pour est, il ne marche qu'en tant que module et a condition de le charger lors du boot (via /boot/loader.conf).
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On Sun, 14 Jan 2007 12:57:47 +0100, Patrick Lamaizière <adresse@est.invalid>
wrote:
patpro ~ patrick proniewski :
Ais-je besoin de charger explicitement cpufreq.ko, ou est ce que
acpi.ko qui est déjà chargé est suffisant ?
powerd marche out-of-the-box
Ben oui. Je me demande à quoi sert le module cpufreq.ko alors ?
C'est un bundle de differents pilotes. Pour est, il ne marche qu'en
tant que module et a condition de le charger lors du boot
(via /boot/loader.conf).
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
On Sun, 14 Jan 2007 12:57:47 +0100, Patrick Lamaizière wrote:
patpro ~ patrick proniewski :
Ais-je besoin de charger explicitement cpufreq.ko, ou est ce que acpi.ko qui est déjà chargé est suffisant ?
powerd marche out-of-the-box
Ben oui. Je me demande à quoi sert le module cpufreq.ko alors ?
C'est un bundle de differents pilotes. Pour est, il ne marche qu'en tant que module et a condition de le charger lors du boot (via /boot/loader.conf).
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Ducrot Bruno
On Sun, 14 Jan 2007 11:33:18 +0100, 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.
On vous a menti. Il y a un bien un powernow. Par contre je ne sais pas s'il marche sur les multiprocesseurs, ni sur les bi-coeurs. Cela necessiterait de toute maniere une modification en profondeur du framework cpufreq afin de prendre en compte tous les cas possibles et pour l'instant seul les monoprocesseurs et dans une moindre mesure les systemes SMP sont pris en compte.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On Sun, 14 Jan 2007 11:33:18 +0100, Eric Masson <emss@free.fr> 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.
On vous a menti. Il y a un bien un powernow. Par contre je ne sais pas
s'il marche sur les multiprocesseurs, ni sur les bi-coeurs. Cela
necessiterait de toute maniere une modification en profondeur du framework
cpufreq afin de prendre en compte tous les cas possibles et pour l'instant
seul les monoprocesseurs et dans une moindre mesure les systemes SMP sont
pris en compte.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
On Sun, 14 Jan 2007 11:33:18 +0100, 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.
On vous a menti. Il y a un bien un powernow. Par contre je ne sais pas s'il marche sur les multiprocesseurs, ni sur les bi-coeurs. Cela necessiterait de toute maniere une modification en profondeur du framework cpufreq afin de prendre en compte tous les cas possibles et pour l'instant seul les monoprocesseurs et dans une moindre mesure les systemes SMP sont pris en compte.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
patpro ~ Patrick Proniewski
In article , Ducrot Bruno wrote:
../..
Il ne faut pas le confondre avec cpufreq.ko, qui est un bundle de differents pilotes comme powernow, est, p4tcc, etc.
plein de précieux renseignements. Merci !
patpro
-- http://www.patpro.net/
In article <slrneqn3q6.ijq.ducrot@neptune.xerus.net>,
Ducrot Bruno <ducrot@echo.fr> wrote:
../..
Il ne faut pas le confondre avec cpufreq.ko, qui est un bundle
de differents pilotes comme powernow, est, p4tcc, etc.
Une sorte de support powernow est chargée : powernow0: <Cool`n'Quiet K8> on cpu0
Mais cela n'apporte pas la possibilité de modifier la fréquence de fonctionnement du cpu en question : $ sysctl -a | grep '^dev.cpu' dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1800 dev.cpu.0.freq_levels: 1800/89000 1800/89000 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0
-- JMM: . GG : Ça c'est un argument percutant. JMM: ça s'appelle un "point de vue" ... -+ JMM in Guide du Macounet Pervers : Point de grands discours ici-là +-
Ducrot Bruno <ducrot@echo.fr> writes:
'Lut,
On vous a menti. Il y a un bien un powernow. Par contre je ne sais pas
s'il marche sur les multiprocesseurs, ni sur les bi-coeurs.
Je ne dispose que d'un vénérable amd64 2800+ socket 754 qui fait tourner
une version 32 bits de FreeBSD (une 6.1 actuellement)
Une sorte de support powernow est chargée :
powernow0: <Cool`n'Quiet K8> on cpu0
Mais cela n'apporte pas la possibilité de modifier la fréquence de
fonctionnement du cpu en question :
$ sysctl -a | grep '^dev.cpu'
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 1800
dev.cpu.0.freq_levels: 1800/89000 1800/89000
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
--
JMM: .
GG : Ça c'est un argument percutant.
JMM: ça s'appelle un "point de vue" ...
-+ JMM in Guide du Macounet Pervers : Point de grands discours ici-là +-
Une sorte de support powernow est chargée : powernow0: <Cool`n'Quiet K8> on cpu0
Mais cela n'apporte pas la possibilité de modifier la fréquence de fonctionnement du cpu en question : $ sysctl -a | grep '^dev.cpu' dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1800 dev.cpu.0.freq_levels: 1800/89000 1800/89000 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0
-- JMM: . GG : Ça c'est un argument percutant. JMM: ça s'appelle un "point de vue" ... -+ JMM in Guide du Macounet Pervers : Point de grands discours ici-là +-
Ducrot Bruno
On Mon, 15 Jan 2007 15:56:59 +0100, Eric Masson wrote:
Ducrot Bruno writes:
'Lut,
On vous a menti. Il y a un bien un powernow. Par contre je ne sais pas s'il marche sur les multiprocesseurs, ni sur les bi-coeurs.
Je ne dispose que d'un vénérable amd64 2800+ socket 754 qui fait tourner une version 32 bits de FreeBSD (une 6.1 actuellement)
Une sorte de support powernow est chargée : powernow0: <Cool`n'Quiet K8> on cpu0
Mais cela n'apporte pas la possibilité de modifier la fréquence de fonctionnement du cpu en question : $ sysctl -a | grep '^dev.cpu' dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1800 dev.cpu.0.freq_levels: 1800/89000 1800/89000
Il y a peut-etre une option BIOS a activer, voire dans certain cas, un bios a upgrader.
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
Je verrai ce que je peux faire.
PS : d'anciennes generations de carte mere a base de nforce ne marcheront pas. Ce n'est pas qu'un probleme de processeurs, et la, il n'y a rien a faire.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On Mon, 15 Jan 2007 15:56:59 +0100, Eric Masson <emss@free.fr> wrote:
Ducrot Bruno <ducrot@echo.fr> writes:
'Lut,
On vous a menti. Il y a un bien un powernow. Par contre je ne sais pas
s'il marche sur les multiprocesseurs, ni sur les bi-coeurs.
Je ne dispose que d'un vénérable amd64 2800+ socket 754 qui fait tourner
une version 32 bits de FreeBSD (une 6.1 actuellement)
Une sorte de support powernow est chargée :
powernow0: <Cool`n'Quiet K8> on cpu0
Mais cela n'apporte pas la possibilité de modifier la fréquence de
fonctionnement du cpu en question :
$ sysctl -a | grep '^dev.cpu'
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 1800
dev.cpu.0.freq_levels: 1800/89000 1800/89000
Il y a peut-etre une option BIOS a activer, voire dans certain
cas, un bios a upgrader.
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
Je verrai ce que je peux faire.
PS : d'anciennes generations de carte mere a base de nforce ne marcheront
pas. Ce n'est pas qu'un probleme de processeurs, et la, il n'y a rien a
faire.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Une sorte de support powernow est chargée : powernow0: <Cool`n'Quiet K8> on cpu0
Mais cela n'apporte pas la possibilité de modifier la fréquence de fonctionnement du cpu en question : $ sysctl -a | grep '^dev.cpu' dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1800 dev.cpu.0.freq_levels: 1800/89000 1800/89000
Il y a peut-etre une option BIOS a activer, voire dans certain cas, un bios a upgrader.
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
Je verrai ce que je peux faire.
PS : d'anciennes generations de carte mere a base de nforce ne marcheront pas. Ce n'est pas qu'un probleme de processeurs, et la, il n'y a rien a faire.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
