Distcc ou openmosix...

Recherche :

Dernière réponse
Sujet : Distcc ou openmosix...
sorg	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 ... :)

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

sorg	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 ... :)

BMOTheKiller

é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é [:spamafote]

[Albator]

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 :(

BMOTheKiller

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...

sorg

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.

BMOTheKiller

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...

sorg	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!

BMOTheKiller

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

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

BMOTheKiller

- 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

sorg

BMOTheKiller a écrit :

real 9m44.717s
user 2m3.737s
sys 0m43.344s

je ne connaissais pas, mais c'est adopté :D
finies les longues compiles de KDE ^^

Ca représente quoi ces differents temps ?

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

BMOTheKiller

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é :D
finies les longues compiles de KDE ^^

sorg	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 ?