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)
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)
Poser une question
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.
Oui.
Je pensais que le portable s'éteindrait plutôt que de faire ça.
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.
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.
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.
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 ]
--
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.