Pour répartir la charge sur plusieurs PC lors de la compilation il vaut mieux utiliser openmosix ou distcc ??
Je sais que openmosix est plus générique mais un soft comme avidemux saura-t-il tirer parti du pseudo SMP mis enplace par openmosix ?

je viens de faire une compile de kernel 2.6.2-mm1 assez chargé pour tester distcc sur un cluster de 3 machines (> 4GHz) et je dois dire que je suis agréablement surpris :
 
time make -j6 bzImage modules CC=distcc
 
real    9m44.717s
user    2m3.737s
sys     0m43.344s
 
je ne connaissais pas, mais c'est adopté
finies les longues compiles de KDE ^^

distcc
 
j'ai fait des tests entre les deux, distcc à un avantage clair, et lui il est stable, et beaucoup plus facile à utiliser efficacement

Ca représente quoi ces differents temps ?

- real : représente le temps réel de la commande, c'est à dire entre le début de son éxécution (par exemple "au moment" où la touche entrée est pressée) et le moment où la commande se termine.
 
- user : le temps CPU utilisé en mode utilisateur (userland)
 
- sys : la même chose mais en mode système (kernelland)
 
ça veut dire que la machine, d'où a été lancée la commande time, a passé 2m 3s 737ms + 43s 344ms, soit 2m 47s 081ms sur la compilation sur les 9m 44s 717ms écoulées

Ok, donc ta compil a duré 9 minutes. et avec un seul PC, tu met combien de temps ?

je sais plus exactement, ça tourne aux environs de 15/20 minutes (bzImage + modules) sur ma config principale, enfin pour un noyau 2.6 chargé comme ça, un 2.4 ça va plus vite

Pour ma part je suis en train de faire le test j'installe Gentoo sur un P3-500 et j'essaie de faire distcc dès le bootstrap en utilisant les ressources de mon dudu 1.2 ... on va voir ce que ca donne!

chaud à mon avis, c'est un peu balaise là, mais bon... fais bien attention à respecter les versions de gcc sur les 2 machines, j'ai essayé avec 2x 3.3.2 + 1x 3.2.1, ça fait pas bon ménage, unresolved symbols + erreurs à gogo (ça se comprend), j'ai finalement passé le vilain canard en 3.3.2...
 
là je compile kde 3.2, ben ça torche, juste eu un unresolved symbol pendant la compile de arts, mais je crois me souvenir que ça ça l'avait fait sur le 3.1.4 en mono-CPU et ça ne m'a jamais posé de problème...

Moi c'est plus la prouesse technique que pour la vitesse de compil car le P3 500 me servira après de gateway + puissance de rab pour la compil et je m'attends pas à un gain de plus de 25 % sur la vitesse de compil (par rapport au dudu seul) . Après j'aimerai bien passer en openmosix pour testezr le clustering pour l'encodage.

essaye dvdrip + transcode
 
c'est vraiment "de la balle", j'ai fait quelques tests sur 2 dvd et je dois dire que j'en suis très content, entre 4 machines je mettais entre 1h30 et 2h00 pour faire matrix en xvid/ac3 2x700 Mo, le partage des ressources est hyper bien foutu et on peut régler la taille des blocs à gérer, tu peux par exemple couper le traitement en 20 blocs comme tu peux le couper en 200 000 blocs, un grand nombre est intéressant quand il y a des petits proco dans le cluster, ils ne ralentiront pas le processus global (c'est un système de dépendances, on doit faire les tâches 1,2,3,N avant N+1,N+2,N+3,N+4, ...), je dois avoir un screenshot qui montre le gestionnaire du cluster quelque part...

J'ai juste trouvé regrettable que dvd::rip, sur 3 PC (Barton 2500, Duron 1600, Tutu 1300) soit plus lent que tuxrip sur mon barton seul

étrange, problème de connectivité peut-être (tout passe par nfs et ssh alors bon...) ? ça tournait bien en fps/cpu sinon ?
 
j'ai pas essayé tuxrip encore, je dois dire que la 1ère fois que j'avais essayé dvdrip je l'ai vite fait jeté, mais les dernières versions sont vraiment un régale, je regrette de ne pas pouvoir faire d'ogg (choix unique entre mp3 et ac3 ), ou alors j'ai mal cherché

Bon, j'ai distcc qui tourne à merveille... Je me fait un petit bench d'ici ce soir...
Vous avez quoi comme compile à me suggerer (autour de 30minutes pour que ca soit significatif mais pas trop casse-bobon ) ?
 
Demain j'essaie dvd-rip en cluster ...