"Areyos Alektor"  a écrit dans le message news:
399ee9e8.0@news.newz.net...
Salut

"Fabian BRAU"  wrote in message
news:399D0C7A.5DDA12E9@umh.ac.be...
>> Une question naive:
>> Si je fais une rendu avec 1 PII 433 ou avec 2 PII 433 je peux
>> esperer gagner au mieux un facteur 2 (2 fois plus rapide),
>> oui ou non?
>non, et en plus les 2 processeurs n'interviennent que pendant le rendu

La problèmatique du calcul en réseau est que tu dois tenir compte de deux
valeurs critiques:
a- Le temps que tu perds lors de la répartition des tâches sur le réseau (il
faut bien que chaque machine reçoive sa part du travail).(temps
incompressible)
b- Celui que tu perds au moment de rapatrier toutes les séries d'images des
différentes machines vers le serveur central.(temps incompressible) Ce
dernier est la plus grosse source de problème chez moi: il montait jusqu'à
un tiers(!!!!) du temps de rendu!!! 7 secs pour envoyer le fichier initial
partout MAIS 2mn 48s pour tout rapatrier!! C'est tout bonnement
insupportable!

C'est cette deuxième valeur qui pose souvent problème dans mon cas car comme
je le disais, mon réseau est en 10 Mb/s ce qui fait qu'il est rapidement
saturé au niveau du rapatriement et que toute vitesse gagnée lors du calcul
par les machines est perdue à ce moment là.
Au moment de la répartition des tâches sur un réseau de 10 Mb/s, passer un
projet (fichier blend+textures) qui dépasse les 5 meg entrainent des
collisions et les données sont incomplètes, le rendu en souffre donc. Il
reste qu'il y a une relative stabilité à l'aller, vu que mes fichirs
n'atteignent pas encore ce chiffre, mais le problème est le retour :-(
Comme vous le savez les fichiers issus d'un rendu peuvent prendre des
proportions astronomiques surtout quand on pousse leur qualité au maximum et
même la compression de pkzip doit plier devant les images nécessaires pour
une animation de 40 secondes en format pal et OSA 8.
ex: 20 images/sec=>800images réparties en 200images/machine. En format
preview et jpg on s'en sort mais en format pal l'inflation est rapide.
Heureusement BOB permet de définir la part de chaque machine et le serveur
réseau peut être de la partie donc j'envoie une grande partie sur lui comme
cela il n'y a pas de problème de rapatriement puisque c'est vers lui que les
fichiers doivent revenir une fois calculés, et les satellites du réseau
n'ont plus qu'à calculer et envoyer des fichiers à dimensions raisonnables.
Evidemment l'ennui est que j'utilise mon réseau vraiment au maximum de ses
capacités mais je ne sais pas si  le type des machines n'est pas la cause
des ralentissements (les machines identiques finissent en même temps
et envoient leurs images=surcharge et ralentissement).
Enfin il n'y a pas d'utilitaire de planification des rapatriement qui
m'enlèverait une sacrée épine du pied :-(

Pour moi cela consiste plutôt à trouver le bon compromis pour ton réseau
mais quand tu l'as trouvé cela te fais quand même gagner du temps de manière
non-négligeable mais tu chipotes sauvagement avant de voir le bout du
tunnel. J'ai aussi l'impression que le seul usage vraiment intéressant est
l'établissement d'une liste de jobs pour BOB et de le laisser travailler.
L'avantage c'est que l'on peut peut éditer une liste de job(travail complet
de rendu avec envoie et raptriement) et aller dormir.
Comme Olivier Saraja (merci, j'ai ainsi pu rêgler le problème de la taille
du fichier principal) me l'avait conseillé en essayant les machines
individuellement puis en pair et enfin toutes ensemble, le goulot
d'étranglement, pour moi, c'est le réseau et à moins de passer à 100 mb/s,
c-à-d quand j'ai de l'argent :-), je suis condamné à rester avec le
rendement et les paramètres que j'ai car ce sont les seuls qui permettent de
me sortir des embarras du raptriement des fichiers sans trop de casse.

>> Si oui avec 4 PII 433 je peux gagner au plus un facteur 4.
>> Dans l'exemple donne ici on gagne un facteur 4.5 et on utilise
>> 4 processeurs dont 3 sont moins rapide qu'un PII 433 (et 2
>> sont beaucoup moins rapide!).
>>
>> Donc :
>>
>> 1) Je ne comprend pas bien (a moins que le fait que ca soit en
>>    reseau joue un role particulier??)

cf a- et b- au dessus, en plus je triche au moment de la répartition des
tâches. :-)
Tu dois en fait te concentrer sur le débit du réseau pour prévoir tout
goulot d'étranglement synonyme de ralentissement important ou pire, dans
notre cas, de collisions aux effets imprévisibles sur l'animation finale.
Tes machines peuvent être des stations SGI si elles sont reliées par un
réseau dont le débit est ridicule la performance générale sera très éloignée
de la vrai capacité des machines.
Quoiqu'il en soit, j'ai appris une chose pour l'instant qui corrobore mes
lectures sur le sujet:
plus le débit de ton réseau est important, plus le facteur de réduction du
temps sera important mais surtout il sera en adéquation avec ton matos :-)
Ah oui j'oubliais: le rendu en réseau n'a de sens que pour l'animation ;-)
(Au cas où quelqu'un voudrait en faire autre chose et s'arracherait les
cheveux)
Voilà ce n'est pas tout mais comme dirait Olivier, avec raison, j'ai des
tests à terminer!
Suite des épisodes en réseau la prochaine fois! Je retourne dans ma pile de
Linux Magazine et les articles sur le clustering :-)

"Ce n'est pas quand tu es au fond du puit qu'il faut remarquer que les
parois sont glissantes"
Proverbe chinois.