j'ai pas eu le temps de tester grandement mon cluster pour le moment, mais
j'ai cru voir qu'il y avait des options de threading dans transcode.
Maintenant l'important c'est de voire comment le kernel va gérer cela.
Ce WE il y aura un portable "puissant", cela permettra de voir comment se
comporte openmosix avec 2 machines de vitesse comparable (duron 1200 +
Celeron 1500) pour les jobs d'encodage.
EN fait openmosix fonctionne bien si on l'aiguille, genre execute telle
tache sur tel noeud.
exemple SANS load balancing sur un K6-400 (noeud2) avec noeud1=duron1200 :
jerome@k6:/tmp/test$ time for i in *.jpg; do convert -geometry 5% $i
./petit/$i ; done
real 1m37.211s
user 0m54.620s
sys 0m17.590s
jerome@k6:/tmp/test$ time for i in *.jpg; do mosrun -1 convert
-geometry 5% $i ./petit/$i ; done
real 0m33.227s
user 0m19.130s
sys 0m6.090s
Par contre si le "noeud 1" coupe openmosix => le script ci dessus plante
(enfin il faut le raffiner)
Mon objectif à terrme, ce serait de faire traiter la bande son par la machine la
plus lente et la bande video par la plus rapide (3x + rapide)
Et ce sans réécrire du code (je sais séparer la video du son, lancer à
distance les jobs et remettre le tout ensemble). Le truc ce serait
d'apprendre à mosix de savoir reconnaitre "transcode" et lui faire faire
ce boulot par lui m^eme.
Par contre c'est clair qu'il faut un reseau RAPIDE entre les machines, il
y a 200ko/s de bruit de fond.
--
Jérôme __ __
/ _) (_ \
_.----._/ / Dinosaurus \ \_.----._
/ / \ \
__/ ( | ( | Psykorigidus | ) | ) \__
/__.-'|_|--|_| |_|--|_|`-.__\