Dorian Fevrier's blog - Mot-clé - reseau - CommentairesJe m’appelle FEVRIER Dorian, je suis infographiste 3D passionné par mon métier, l’informatique en général, l’internet, la programmation et l’évolution de tout ce petit monde. Vous trouverez sur ce blog des tutoriaux, mes coups de cœurs, avis, etc.2024-01-02T23:48:05+01:00FEVRIER Dorianurn:md5:695d9c73474c33ce3dab043823509c4bDotclearRésoudre les ralentissements réseaux dûs a Nuke, After Effect et autres logiciels du genre - Dorianurn:md5:5fbbac1ed417f8cd94663408ab612f552013-10-28T22:55:40+01:002013-10-28T22:56:01+01:00Dorian<p>Je n'ai pas bien compris ton message. ^^'</p>
<p>Comme je l'explique dans le billet, le problème n'est pas tant le poids que le nombre d’écriture. Sur un gros réseau, il est souvent préférable de faire moins d’accès en écriture mais que ces accès écrivent beaucoup de données plutôt que l'inverse.</p>
<p>Donc il vaut mieux transférer l'image en un seul morceau sur le réseau (rendre dans un temp local et envoyer le fichier une fois fini) plutôt que laisser Nuke faire environs 1000 accès en écriture par image. :D</p>Résoudre les ralentissements réseaux dûs a Nuke, After Effect et autres logiciels du genre - Mitchurn:md5:a4208f7539a32eb053c0132e536821d02013-10-28T22:29:01+01:002013-10-28T22:46:05+01:00Mitch<p>Soit, donc en exr multichannel, où en HD tu peux monter à 100mo la frame avec toutes les passes d'illumination plus des passes de datas, le problème est assez récurrent (en particulier avec des gizmos un peu sophistiqués) et cette solution est réellement efficace.<br />
Par contre, c'est donc sensible aussi en batch et également sur une farm, pas uniquement en interactif (je ne rends presque jamais en interactif sauf des tout petits trucs) - à base de trucs "collés" pendant 2h avec les cpus qui branlent rien qui passent à 10-15 minutes.</p>Résoudre les ralentissements réseaux dûs a Nuke, After Effect et autres logiciels du genre - Dorianurn:md5:a13e77415db4ec8aefcef7bcdb9caf1e2013-10-28T21:04:00+01:002013-10-28T21:05:24+01:00Dorian<p>Oui, mais comme tu dis, ça dépend des footages. :D</p>
<p>L'attribut "cached" est a mon sens, pensé pour de l'interactif. Il ne fait "que" écrire une image d'un node (qui a priori ne va pas trop changer) en local pour gagner du temps lors d'une évaluation/d'un accès futur. C'est en fait plus tricky que ça car si tu bosse en zoom 50% (demi-résolution), "cached" n'écrira que cette demi résolution (et uniquement les "zones" que ton viewer a demandé). Au final, l’intérêt est mince car quand le script Nuke doit être calculé en rendu def, c'est toutes les images du plan qui doivent "passer a la moulinette" et en full résolution ce qui représente finalement une partie assez mince de ce que tu auras pu "choper" avec l'attribut "cached". Si en plus tu lance en farm, tout ce que tu a "chopé" avec "cached" n'existera tout simplement pas sur les farms.</p>
<p>Puis il faut voir les compos aussi. Sur ce projet, il n’était pas rare d'avoir des "Too Many Open Files", les exr étant splitte en post rendu pour éviter le multichannel et gagner en vitesse (ce qui augmente nécessairement la charge réseau, d’où le boulot nécessaire pour l'utiliser intelligemment).</p>
<p>Je rajouterai qu'un système similaire a "cached", plus évolué, avait été développé pour créer des "points de rendu" dans le graph, mais il nécessitait d'avoir un graph propre, ce qui est toujours difficile au fils des retakes.</p>
<p>Content que mon blog te plaise sinon. :)</p>Résoudre les ralentissements réseaux dûs a Nuke, After Effect et autres logiciels du genre - Mitchurn:md5:75bf38c0d902f8381f00e5717b8c2d202013-10-28T20:07:43+01:002013-10-28T20:16:41+01:00Mitch<p>Un truc qui peut aussi vraiment changer la donne selon les footages utilisés dans une compo Nuke.<br />
C'est l'attribut "cached" d'un node... en particulier sur des footages exr multichannel avec plein de passes dedans, ça utilise plus de ram mais ça évite que nuke passe des plombes à boucler comme un fou-furieux pour évaluer le network de la comp parce qu'il accède aux fichiers sources en permanence dès qu'il a besoin d'une info.<br />
Sur certaines compos j'ai eu des différences vraiment spectaculaires de temps de rendu.<br />
Sinon super blog, c'est une mine d'information.</p>Résoudre les ralentissements réseaux dûs a Nuke, After Effect et autres logiciels du genre - Dorianurn:md5:930dc60c6741033577748ba439ec01732013-06-15T14:08:07+02:002013-06-15T13:08:43+02:00Dorian<p>Héhé! Content que ça puisse aider, c'est le but!</p>
<p>Si en plus ça sauve des prods! ^^</p>Résoudre les ralentissements réseaux dûs a Nuke, After Effect et autres logiciels du genre - Edouard Sisternasurn:md5:c24eeb9e38016f74b42ef945d83394d32013-06-15T12:57:08+02:002013-06-15T13:06:02+02:00Edouard Sisternas<p>Je n avais pas encore eu le temps de te dire merci, grâce à toi j ai réussi à sauver la serie sur laquelle je bossais. Merci pour tout tes billets et à très bientôt à mac guff pr que je puisse t offrir une peinte en remerciement :D</p>Résoudre les ralentissements réseaux dûs a Nuke, After Effect et autres logiciels du genre - Francois "CoyHot" Grassardurn:md5:f1c276f88724f7eca7626a1b70c75b8d2012-12-26T11:41:21+01:002012-12-26T11:46:58+01:00Francois "CoyHot" Grassard<p>Je t'en prie ... c'est un plaisir ! :o)<br />
Et merci à toi pour ton dossier initial ... :o)</p>Résoudre les ralentissements réseaux dûs a Nuke, After Effect et autres logiciels du genre - Dorianurn:md5:98f986139dfa45bce3a2beb439e947952012-12-26T11:17:39+01:002012-12-26T11:17:54+01:00Dorian<p>Outch! Super intéressant ton billet. Beaucoup d'astuces que je ne connaissais pas ou de loin (FrameServer je l'avais oublie celui la! :D ).</p>
<p>Je vois que tu a bien potasse le truc, chapeau!</p>
<p>Merci beaucoup pour ce commentaire très instructif! :)</p>Résoudre les ralentissements réseaux dûs a Nuke, After Effect et autres logiciels du genre - Francois "CoyHot" Grassardurn:md5:0de3c895b2efc315ffabf44e0092c5e02012-12-23T01:17:33+01:002012-12-26T10:34:08+01:00Francois "CoyHot" Grassard<p>Mon avis personnel sur la gestion du Multicore de After Effects est "trop aléatoire pour qu'on puisse lui faire confiance".</p>
<p>Il est efficace si on utilise énormément de pré-compositions car le contenu de chacune d'entre elle peut-être calculé en parallèle. Mais une fois que leur résultat doit être mixé avec les pré-compos supérieure dans la même compo ... ben là on retombe en monocore. Si tu n’utilises aucune pré-composition (ce qui est ridicule sur un gros projet, on est d'accord), alors tout le calcul sera monocore.</p>
<p>After FX ne traite pas une image par Bucket, comme le fait le module de compositing de Blender par exemple. Pas de Tile rendering ici.</p>
<p>Le moteur de rendu de After FX fonctionne par calque. Il superpose les deux calques les plus bas dans la pile, stock le résultat dans un buffer, puis il considère son contenu comme un nouveau calque, auquel il superpose le calcul supérieur et ainsi de suite. Par conséquent, le calcul se fait toujours avec seulement deux calques ... avec éventuellement la pondération d'un troisième lors de l'utilisation d'un "Track Matte".</p>
<p>Ce n'est donc pas sur le calcul d'une image qu'il faut penser optimisation Multi-core avec After FX ... mais calcul de plusieurs images indépendantes en même temps. "aerender" est pour cela la meilleure solution car on peut le scripter et l'intégrer dans un processus plus large.</p>
<p>psExec a pour avantage de pouvoir lancer des appli (aerender ou batch le contenant) à distance ... à travers le réseau. Mais il peut aussi te servir à commander des scripts locaux installer sur les machines, utilisant des commandes "start" qui permettent de définir la priorité des processus et l'affinité de ceux-ci sur un nombre limité de core (un petit "start /?" dans une fenêtre prompt/dos like te donnera toutes les commandes). Tu codes ainsi une appli qui s'occupe de lancer des aerender sur chaque proc, en activant l'option (uniquement valable pour le calcul en séquence d'images) permettant de ne calculer que les images manquantes. Là ... tu as vraiment 100% de tes procs à bloc ... tout le temps ! Bien évidemment, l'utilisation de la RAM est multiplié ... mais tu peux via le menu "Secret", demander à ce que la RAM soit vidée souvent afin d'éviter le Swapping.</p>
<p>aerender ne demandant pas de licence ... tu peux même l'installer sur les machines de la compta ... :o) Tu lances à distance avec psexec des calculs en priorité basse en limitant la RAM utilisée dans les paramètres de aerender ... et personne ne se rend compte que sa machine calcule pour toi . :o) J'ai personnellement usé et abusé de cette méthode pendant 4 ans, quand j'étais chef de studio ... :o) Crois-moi ... on gagne des jours et des jours de calculs. Potentiellement, tout le monde sert au calcul. Et quand les gens se casse pour bouffer ou dormir ... toute la puissance de leur machine est pour toi.</p>
<p>Pour le réseau, tu as plusieurs solutions, dont certaines sont parfois à utiliser en même temps :</p>
<p>- Tu peux calculer en local et lancer les transferts la nuit sur le serveur. C'est long ... mais pour ça, j'ai une petite méthode perso. Tu n'es pas sans savoir j'imagine que transférer plein de petits fichiers est plus long que d'en transférer un gros. Voilà ce que j'avais l'habitude de faire : Zipper les images (j'utilise maintenant le 7z qui est à mon sens bien plus efficace) ... et commencer le transfert du Zip ... alors que celui-ci n'est pas encore fini d'être crée ! Impossible via une copie simple me diras-tu. Oui, c'est vrai ... mais via un transfert FTP c'est possible, si le client réactualise le transfert en fonction du poids du fichier à chaque trame de réseau (la plupart des clients FTP le le font). Et tu peux même te payer le luxe de dézipper le fichier qui n'est pas encore fini d'arriver si tu es sous Linux. :o) Tu peux aussi créer un zip (ou 7z) directement sur la machine distante à partir des multiples fichier locaux. C'est BEAUCOUP plus rapide que de copier les fichiers un à un. :o)</p>
<p>- Tu peux effectuer un collect files en local des fichiers avant de lancer le calcul. Ainsi, n'auras que les transferts en sortie à gérer et pas les entrées. J'ai personnellement écrit mon propre collect files, intégrant plein de bidouilles pour accélérer les transferts ... de plus, celui de After FX plante lorsqu'on essaye de transférer des fichiers de plus de 4Go sur des transferts 32 bits. Donc ... on est jamais aussi bien servi que par soit-même. :o)</p>
<p>- Autre solution que j'ai mis en place à une époque ... mais c'est plus couteux : Chaque machine à deux cartes réseaux, dont les entrées/sorties passent par deux réseaux de switch différents. Ainsi, la lecture et l'écriture ne passe pas par les même tuyaux. :o) Un peu chiant ... mais efficace. Là encore, il faut coder soit même les transferts pour contrôler les flux sur deux serveurs différents.</p>
<p>- La façon dont After FX gère les séquences d'images sur le réseau est très étrange. Il ouvre le socket, charge l'image, ferme le socket et ainsi de suite pour toutes les images. Lorsque tu utilises un Movie (QT, AVI, etc ..), le socket reste ouvert et le flux de transfert est BEAUCOUP plus rapide.<br />
J'ai fait une expérience il y a quelques années. Nous utilisions des stockshots de flammes/fumée/etc de chez Artbeats dans nos projets. Nous les avions acheté en séq d'images TGA (beurk). Je les avais converti en PNG pour limiter les transferts via le serveur de StockShot (home made avec une slackware). J'ai ensuite encapsulé ces mêmes images dans un Quicktime / Codec PNG. Donc des images strictement identiques ... mais encapsulées dans un seul fichier MOVIE.</p>
<p>En chargeant la séq d'images dans After FX ... la RAM preview (sans effet) était d'environ 1X le temps réel (25 FPS). En lisant le QT ... 12X le temps réel ! Pour les même images !!! Tu vois un peu l'avantage que ce type de conversion peu avoir.</p>
<p>Bien sur tu vas me dire ... oui mais à la boite il ne veulent pas travailler avec des MOVIES ... ils ne font que de la seq d'images. Et bien c'est pas grâve ... tu n'as cas mentir à la machine en mettant sur le serveur un FrameServer. Tu crées un faux fichier AVI par exemple, qui link vers la séquence. FFMPEG fait ça très bien, avec AVI Synth et le FS de DebugMode. Un petit exemple ici, où on utilise FFMPEG pour l'encodage dans Premiere Pro :</p>
<p><a href="https://ffmpeg.org/trac/ffmpeg/wiki/FFmpegPremierePro" title="https://ffmpeg.org/trac/ffmpeg/wiki/FFmpegPremierePro" rel="ugc">https://ffmpeg.org/trac/ffmpeg/wiki...</a></p>
<p>- Autre astuce : si tu fais ton propre système de gestion de rendu, tu peux lancer une copie pendant que l'image suivante calcule ... plutôt que d'avoir le cycle habituelle rendu/copie/rendu/copie. Là encore, la commande "start" permet de lancer des processus différents sur différents core ... en même temps. On peut d'ailleurs les appeler dans les scripts JSX de After FX. :o)</p>
<p>Voilà ... ce ne sont que quelques astuces par rapport à tout ce qu'il est possible de faire ... mais si ça peut t'aider. :o) Cela fait des années que je me dis qu'il faudrait que je publie une petit dossier sur la chose, ayant déjà largement creusée la question ... mais tu connais le problème. Le temps, mon ami ... le temps ... :)</p>Résoudre les ralentissements réseaux dûs a Nuke, After Effect et autres logiciels du genre - Dorianurn:md5:666695aa136d4c2ea03407312035572a2012-12-21T15:17:16+01:002012-12-21T15:17:37+01:00Dorian<p>C'est bon ça! :D</p>
<p>Par contre le soucis présenté ici c'est que si il y a des AE lisent ET écrivent sur le réseau, c'est la que ça plombe tout.</p>
<p>Ton outil écrit les images en local puis les copies dans le dossier de destination? Ou il les écrit directement dans le dossier sur le réseau?</p>
<p>Après, peut être qu'en effet c'est le multicore de AE (et potentiellement Nuke) qui écrit de manière peut être un peu barbare et plombe le réseau....</p>
<p>Au final, je n'ai jamais teste de rendre en monocore pour voir si le soucis était toujours la mais je prend bonne note! :)</p>Résoudre les ralentissements réseaux dûs a Nuke, After Effect et autres logiciels du genre - Francois "CoyHot" Grassardurn:md5:2b47eb898525be0f93062c6ccda0ab1d2012-12-21T13:29:23+01:002012-12-21T15:09:49+01:00Francois "CoyHot" Grassard<p>Voilà pourquoi je me suis fait depuis quelques années mon propre render manager pour After FX ... :o)</p>
<p>Son but est de lancer des aerender en ligne de commande en assignant chaque aerender à un processeur en particulier. Cela permet de ne pas utiliser la gestion (pas très efficace) des multicores dans AfterFX et d'avoir toujours des procs à 100 %.</p>
<p>Sous Windows, j'utilise pour ça psexec, qui depuis fait partie de Microsoft :</p>
<p><a href="http://technet.microsoft.com/fr-fr/sysinternals/bb897553.aspx" title="http://technet.microsoft.com/fr-fr/sysinternals/bb897553.aspx" rel="ugc">http://technet.microsoft.com/fr-fr/...</a></p>
<p>Cerise sur le gateau, on peu lancer des aerender à distance sur des machines qui se trouve sur le réseau (donc on peu utiliser toutes les machines du parc).</p>
<p>J'ai un bacth sur lequel je glisse mon *.aex, qui du coup le prends en argument, calcule la RAM restante, en divise le nombre par le nombre de proc et passe cette info à la ligne de commande de aerender.exe en tant que ram maximum à utiliser.</p>
<p>Ainsi, je ne swap jamais et mes 8 cores tournes à 100%. Lors de rendu de séquence d'images, je check la taille du fichier pour savoir si il est fini de calculer et ainsi je lance la copie sur le serveur distant ... ou alors je raccorde le tout à FFMPEG pour en produire un movie.</p>
<p>Je suis en train de coder une appli en QT pour pouvoir choisir le nombre de proc à utiliser sans changer les infos dans le Batch. :o)</p>Résoudre les ralentissements réseaux dûs a Nuke, After Effect et autres logiciels du genre - lucien fostierurn:md5:7edbd57541b617724dc0caf88819efc12012-11-01T23:01:11+01:002012-11-02T01:05:23+01:00lucien fostier<p>thanks for sharing</p>Résoudre les ralentissements réseaux dûs a Nuke, After Effect et autres logiciels du genre - Tristanurn:md5:27813028144f91a2729cbbaf99ec1a052012-10-20T15:53:58+02:002012-10-21T18:15:37+02:00Tristan<p>:D</p>Résoudre les ralentissements réseaux dûs a Nuke, After Effect et autres logiciels du genre - Dorianurn:md5:9a2714448ea5d8ec3d44b73a119937d72012-10-17T11:18:28+02:002012-10-19T21:35:26+02:00Dorian<p>Hi Tristan!</p>
<p>As it's a frequent problem I will find time to translate this one. ;)</p>
<p>EDIT: <a href="https://www.fevrierdorian.com/blog/post/2012/10/19/Resolve-network-slowdowns-due-to-Nuke-After-Effects-and-other-softwares-like-them" rel="ugc">And there</a> the English translation. :sourit:</p>Résoudre les ralentissements réseaux dûs a Nuke, After Effect et autres logiciels du genre - Tristanurn:md5:b923f4df6a2ed89115de634f157c5fbb2012-10-17T11:10:03+02:002012-10-17T10:16:58+02:00Tristan<p>No english :(</p>