encodage video, core2duo et performance

Le
Hugolino
Salut,

J'ai un problème de performance quand j'utilise mencoder pour encoder de
la vidéo sur un Packard Bell EasyNote MH45 dont le proc est un core2duo
T3200 à 2GHz.

L'encodage commence avec une vitesse de 100 ou 120 fps (ce qui
correspond à une durée d'encodage d'environ une demie-heure pour un film
de deux heures), puis, après quelques minutes, la vitesse d'encodage
affichée par mencoder se dégrade (et la durée prévue augmente en
conséquence) jusqu'à tomber aux environs de 3 ou 4 fps (et une durée de
plusieurs heures) et bien sûr je laisse tomber.

J'ai vérifié, avec cpufreq-info, que les processeurs tournaient bien à
2GHz (et le gouverneur est bien 'performance') et d'ailleurs la
température grimpe jusqu'à 90/91°C.

J'avais repéré dans /var/log/kern.log que cette dégradation des
performances de mencoder était concomitante à l'apparition de "CE: hpet
increasing min_delta_ns to 113904 nsec". La solution googlisée était
d'ajouter l'option "hpet=disable" au chargement du noyau (et 'cat
/proc/cmdline' atteste de sa prise en compte).

Ça n'est bien évidemment pas la vitesse de lecture du disque qui limite
la vitesse d'encodage puisque le PC n'a aucun problème pour transmettre
ce fichier de 5 Go à travers le réseau en moins de 10 minutes vers
mon vieil Athlon 2400+ (à 2GHz lui aussi) pour qu'il encode avec la même
version de mencoder, à 60fps, c'est à dire en moins d'une heure.

Les deux PC tournent sous Debian/Lenny, avec un noyau 2.6.31-1-686.

Sur le core2duo, mencoder raconte:
8<--8<8<-8<-8<-8<-8<
MEncoder dev-SVN-r26940 (C) 2000-2008 MPlayer Team
CPU: Intel(R) Pentium(R) Dual CPU T3200 @ 2.00GHz (Family: 6, Model:
15, Stepping: 13)
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.
8<--8<8<-8<-8<-8<-8<

Sur l'athlon2400+, on voit:
8<--8<8<-8<-8<-8<-8<
MEncoder dev-SVN-r26940 (C) 2000-2008 MPlayer Team
CPU: AMD Athlon(tm) XP 2400+ (Family: 6, Model: 8, Stepping: 1)
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0
Compiled with runtime CPU detection.
8<--8<8<-8<-8<-8<-8<

Que pourrais-je essayer pour éviter que le core2duo ne pédale dans la
semoule avec mencoder ?


Merci de vos avis


[xp: fcolc ; fu2: fr.comp.sys.pc]


--
No animals were harmed and no Microsoft products were used in the production
of this message.
Hugo (né il y a 1 473 122 865 secondes)
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Fabien LE LEZ
Le #22997241
On Thu, 6 Jan 2011 19:50:04 +0100, Hugolino
et d'ailleurs la
température grimpe jusqu'à 90/91°C.



Ce qui est largement assez pour que le processeur panique et se mette
en rideau.

Un vieux Athlon à cette température s'arrêterait carrément ;
le Core2 Duo se contente de réduire considérablement sa consommation
(et donc ses performances). C'est un mode "panique", indépendant des
réglages de fréquence/tension de la carte mère.

Enfin bref, le ventirad est foiré. Essaie de le nettoyer, voire de le
changer.
Hugolino
Le #22998511
Le 07-01-2011, Fabien LE LEZ
On Thu, 6 Jan 2011 19:50:04 +0100, Hugolino
> et d'ailleurs la température grimpe jusqu'à 90/91°C.

Ce qui est largement assez pour que le processeur panique et se mette
en rideau.



Oui.

Un vieux Athlon à cette température s'arrêterait carrément ; le Core2
Duo se contente de réduire considérablement sa consommation (et donc
ses performances). C'est un mode "panique", indépendant des réglages
de fréquence/tension de la carte mère.



Je pensais que le portable s'éteindrait plutôt que de faire ça.

Enfin bref, le ventirad est foiré. Essaie de le nettoyer, voire de le
changer.



OK.

Pour valider ta théorie, il faudrait que je lance un programme qui
chargerait le processeur à 100% et qui afficherait le nombre d'itération
qu'il effectue chaque seconde. Si tu as raison le nombre d'itération par
seconde s'écroulera franchement quand la température atteindra cette
valeur de 90°.
Tu aurais ça en magasin ?

(du coup, retour sur fcolc)


--
PRIORITY ONE
INSURE RETURN OF ORGANISM FOR ANALYSIS.
ALL OTHER CONSIDERATIONS SECONDARY.
CREW EXPENDABLE.
Fabien LE LEZ
Le #22998801
On Fri, 7 Jan 2011 15:47:01 +0100, Hugolino
Tu aurais ça en magasin ?



C'est très facile à bricoler en C :

#include #include
void burn()
{
int i, a;
for (i=0; i<100000000; ++i)
{
a*= 3;
}
}

int main()
{
for (;;)
{
clock_t start, end;
start= clock();
burn();
end= clock();
printf ("%f / seconden", CLOCKS_PER_SEC /
(double) (end - start));
}
}


Il faut compiler sans optimisation :

gcc -o truc truc.c
./truc

Tu devras sans doute lancer deux instances, histoire d'occuper les
deux coeurs.
Fabien LE LEZ
Le #22998791
On Fri, 7 Jan 2011 15:47:01 +0100, Hugolino
il faudrait que je lance un programme [...] quand la température atteindra cette valeur de 90°.



Tu fais ce que tu veux de ton matériel, mais si mon processeur atteint
une telle température, je ne fais pas ce genre de tests. J'éteins la
machine, et je répare le ventilateur.
Hugolino
Le #23001561
Le 07-01-2011, Fabien LE LEZ
On Fri, 7 Jan 2011 15:47:01 +0100, Hugolino
>Tu aurais ça en magasin ?

C'est très facile à bricoler en C :

[cf les 23 lignes de code que je rejette en fin de post]



OK, merci beaucoup.

J'ai donc exécuté ton programme, et les résultats sont concluants:

Si je règle le gouverneur des CPU sur "performance", c'est à dire que je
bloque leurs fréquences sur la valeur maximum (2Ghz), ton programme
affiche chaque seconde une ligne "2,5 / seconde" pendant que la
température grimpe tranquillement vers 93°C en une dizaine de minutes.

Environ une à deux minutes après avoir atteint cette valeur (et c'est ce
décalage qui m'a géné pour en tirer la juste conclusion que tu as
suggérée), le nombre d'itérations affiché par ton programme tombe à
environ "0,5 / seconde" (j'ai même fait un test par ssh pendant que
ce portable était utilisé sous Firefox et j'avais obtenu des valeurs
inférieures à "0,2 / seconde") et la témpérature redescend (légèrement)
à 87/88 °C

J'ai ensuite réglé la fréquence des CPU à 1,33 GHz : ton programme
tourne alors à "1,666667 / seconde", ce qui est bien proportionnel à la
fréquence.

Mais l'avantage de limiter ainsi la fréquence, c'est que la température
plafonne à 77 °C et donc que le nombre d'itération par seconde reste
constant et ne se dégrade plus.

Ça ressemble quand même bien à un bug du CPU, puisqu'il vaudrait bien
mieux qu'il abaisse de lui-même la fréquence, voire qu'il éteigne le PC
(comme le fait mon Athlon de 9 ans d'âge) plutôt que de rester à essayer
d'exécuter ce programme avec des performances très dégradées et sans que
la température revienne vers des valeurs plus normales...

C'est tout de même bizarre que lorsqu'on a besoin de toute la
performance de ce portable, il vaille mieux utiliser le gouverneur
"powersave" plutôt que le "performance".

Merci encore de ton aide, je vais voir si j'arrive à ouvrir ce portable
pour nettoyer son ventirad...


[xp fcolc/fcsp ; fu2 fcsp ]


#include #include
void burn()
{
int i, a;
for (i=0; i<100000000; ++i)
{
a*= 3;
}
}

int main()
{
for (;;)
{
clock_t start, end;
start= clock();
burn();
end= clock();
printf ("%f / seconden", CLOCKS_PER_SEC /
(double) (end - start));
}
}


Il faut compiler sans optimisation :

gcc -o truc truc.c
./truc

Tu devras sans doute lancer deux instances, histoire d'occuper les
deux coeurs.





--
Et puis quitte à faire du second degré, j'aurais plutôt misé sur un bon
gros .pps avec des zoulies zanimations, et plein de VB derrière.


Comme d'habitude, dès qu'on commence à parler de MS Word, c'est
l'escalade vers l'horreur... Les gens sont vraiment scato par nature.
Boulu
Le #23003481
On Sat, 8 Jan 2011 17:49:09 +0100, Hugolino
Le 07-01-2011, Fabien LE LEZ
On Fri, 7 Jan 2011 15:47:01 +0100, Hugolino
>Tu aurais ça en magasin ?

C'est très facile à bricoler en C :

[cf les 23 lignes de code que je rejette en fin de post]



OK, merci beaucoup.

J'ai donc exécuté ton programme, et les résultats sont concluants:

Si je règle le gouverneur des CPU sur "performance", c'est à dire que je
bloque leurs fréquences sur la valeur maximum (2Ghz), ton programme
affiche chaque seconde une ligne "2,5 / seconde" pendant que la
température grimpe tranquillement vers 93°C en une dizaine de minutes.

Environ une à deux minutes après avoir atteint cette valeur (et c'est ce
décalage qui m'a géné pour en tirer la juste conclusion que tu as
suggérée), le nombre d'itérations affiché par ton programme tombe à
environ "0,5 / seconde" (j'ai même fait un test par ssh pendant que
ce portable était utilisé sous Firefox et j'avais obtenu des valeurs
inférieures à "0,2 / seconde") et la témpérature redescend (légèrement)
à 87/88 °C

J'ai ensuite réglé la fréquence des CPU à 1,33 GHz : ton programme
tourne alors à "1,666667 / seconde", ce qui est bien proportionnel à la
fréquence.

Mais l'avantage de limiter ainsi la fréquence, c'est que la température
plafonne à 77 °C et donc que le nombre d'itération par seconde reste
constant et ne se dégrade plus.

Ça ressemble quand même bien à un bug du CPU, puisqu'il vaudrait bien
mieux qu'il abaisse de lui-même la fréquence, voire qu'il éteigne le PC
(comme le fait mon Athlon de 9 ans d'âge) plutôt que de rester à essayer
d'exécuter ce programme avec des performances très dégradées et sans que
la température revienne vers des valeurs plus normales...

C'est tout de même bizarre que lorsqu'on a besoin de toute la
performance de ce portable, il vaille mieux utiliser le gouverneur
"powersave" plutôt que le "performance".



Ce qui n'est pas normal, c'est qu'il chauffe à ce point.
Normalement tu devrais pouvoir l'utiliser à sa puissance maxi sans
limitation de temps.
Les programmes réduisant la puissance ne sont là que pour économiser
les batteries, pas le proc.

Les ventilos tournent 'ils, ne sont 'ils pas trop encrassés ?
N'y a t'il rien qui empêche l'air de circuler ?
Hugolino
Le #23005691
Le 09-01-2011, Boulu

[????]




Le 07-01-2011, Fabien LE LEZ
On Thu, 6 Jan 2011 19:50:04 +0100, Hugolino
> et d'ailleurs la température grimpe jusqu'à 90/91°C.

Ce qui est largement assez pour que le processeur panique et se mette
en rideau.

[...]

Enfin bref, le ventirad est foiré. Essaie de le nettoyer, voire de le
changer.




--
Je pense que tous ceux qui ne pensent pas que je sois assez malin pour la tàche
présidentielle sont en deçà de la réalité. (US News & world report. 3.4.2000)
Hugo (né il y a 1 474 106 785 secondes)
wcth
Le #23029591
On 07/01/2011 16:57, Fabien LE LEZ wrote:
On Fri, 7 Jan 2011 15:47:01 +0100, Hugolino
Tu aurais ça en magasin ?


C'est très facile à bricoler en C :

#include #include
void burn()
{
int i, a;
for (i=0; i<100000000; ++i)
{
a*= 3;
}
}

int main()
{
for (;;)
{
clock_t start, end;
start= clock();
burn();
end= clock();
printf ("%f / seconden", CLOCKS_PER_SEC /
(double) (end - start));
}
}


Il faut compiler sans optimisation :

gcc -o truc truc.c
./truc

Tu devras sans doute lancer deux instances, histoire d'occuper les
deux coeurs.





Très marrant ce test sur un Phenom II 1090T

1 instance : 5,000000/s
2 instances : 4,761905/s
3 instances : 4,545455 et 4,761905/s alternés
4, 5 et 6 instances : 4,347826/s

Je crois avoir lu quelque part que la fréquence diminue si beaucoup de
coeurs sont utilisés.
La température passe de 32° à 44° au bout de 10mn
moi-meme
Le #23031111
Le Mon, 17 Jan 2011 16:27:06 +0100, wcth a écrit :

Très marrant ce test sur un Phenom II 1090T

1 instance : 5,000000/s
2 instances : 4,761905/s
3 instances : 4,545455 et 4,761905/s alternés 4, 5 et 6 instances :
4,347826/s

Je crois avoir lu quelque part que la fréquence diminue si beaucoup de
coeurs sont utilisés.
La température passe de 32° à 44° au bout de 10mn



(réflexion gratuite un peu trollesque)

n'y aurait-il pas une puissance dégagée au "mètre carré de silicium" pour
une même fréquence ?

2 cœurs = 2 fois plus de surface = 2 fois plus de dissipation.

N'y a t'il pas (à technologie égale) un "°C/flop" ?

qui fait que la puissance de calcul est plus limitée par le radiateur que
par l'architecture ?

N'est-ce pas la raison de la vogue des clusters plutôt que les Cray x ?
Publicité
Poster une réponse
Anonyme