OS:
Operating system requirements.
Main Server:
Whether an application has a main server. Often its more comfortable to manage all users and all their jobs through server administration.
Host Resources:
What kind of resources render nodes send to server. CPU, memory and disk usage are usually present. Its good to know about SWAP usage as it can slow down process. Detailed CPU usage can be also very useful, whether it renders a task or perform some system operations or wait some IO devices. Network traffic can help you to find out network speed problems.
Task Dep:
Tasks dependence. Some job tasks can wait other job task (s) to be done to run. For example all frames can be started after some simulation and each frame can be stared after 2 its shadows.
Var CPU:
Software usually support specifying the number of CPUs in command line. Manager can learn rules for every application to vary tasks "power". This can help to fit render resources with tasks better. But only if manager supports previous ability (Multi Task Host).
Multi Host Task:
Some render applications supports running one frame on several hosts: "RenderMan NET Render", "Mantra multi host render", "Houdini 10 simulations".
Task Output Parsing:
The way manager parses task output (stdoutstderr). The best way is a Python class. Python is programming language - it is flexibility. Class is not only method, you can store some useful data. Class inheritance - you can write come base basic classes and inherit them for more complex parsers.
Порівняння Менеджерів Рендер Ферми.
Пам'ятайте, Alfred. який взагалі без "утиліт", найбільш поширений у великих конторах як у "нас" так і у "них". Не важливо що вже вміє робити диспетчер, важливо щоб його можна було навчити чого завгодно. Як конструктор.
OS:
Під яку операційну систему існує програма або її частина - сервер, інтерфейс, клієнт.
Main Server:
Наявності головного сервера у диспетчера. Як це не дивно може здатися підкованому людині, але у деяких диспетчерів його немає. Це може привести до незручності його адміністрування. Наприклад неможливо на час кому-то что-то заборонити або управляти чужою завданням.
Host Resources:
Тип ресурсів присилаються рендером. Зазвичай є завантаженість процесора (ів) і пам'яті. Добре якщо приходить інформація про SWAP, так як його використання може сильно уповільнити процес. Корисно мати детальну інформацію про використання CPU, чи вважає він вашу сцену або виконує якісь системні операції, а може просто чекає введення-виведення. Інформація про мережевий трафік може допомогти зрозуміти проблеми зі швидкістю мережі.
Job Dep:
Залежності між завданнями. Одна або кілька завдань можуть чекати виконання іншої залежною (інших залежних). Дуже корисно, поставили вважатися 3d, потім залежний "компози" (і йдете до свого дому).
f - Завдання може залежати від іншої "покадрово". Тобто порахувався 5ий кадр одного завдання, може вважатися 5ий кадр інший. Часткове вирішення залежності між кадрами для диспетчера який не підтримує залежності між подзадачами. Але в загальному випадку у вас може не співпасти, наприклад, 5ий кадр 3d і 5ий кадр композітінга (хіба мало який offset або retime ви там зробили або багато ще чого).
Task Dep:
Можливість поставити залежності між подзадачами. Наприклад вважаємо для кадру спочатку 2е тіні, а потім сам кадр або, для композітінга, спочатку задник, потім кей, потім фінальні dpx-и (і жпегі для превью).
Several Clients Same Host:
Можливість запустити кілька клієнтських програм на одному комп'ютері. Це найпростіший спосіб змусити клієнта вважати одночасно ще якісь завдання, але ця функція менш потрібна в разі якщо клієнт підтримує Multi Task Host. Інший клієнт може бути зовсім по-іншому налаштований і використовуватися для спеціальних завдань. Може стане в нагоді для "дебага" або просто для тестів чогось нового.
Multi Task Host:
Один клієнт може запускати кілька завдань одночасно. Дуже корисно для ферм з різними по потужності комп'ютерів і різними за складністю завданнями, особливо коли і те й інше одночасно (що аж ніяк не рідко). Більш сильна машина може одночасно вважати більшу кількість різних підзадач. І більшу кількість легких подзадач можуть одночасно вважатися на одному комп'ютері. Більш збалансоване використання ферми, так як менше "простою" - це коли клієнт вважає щось легке, що майже не віднімає ресурсів, але для диспетчера він "зайнятий" і більше йому нічого не пропонується робити (так як зазвичай у таких диспетчерів клієнт або "зайнятий" або "вільний" і відсутнє поняття "наскільки він зайнятий").
Var CPU:
Нерідко буває, що в командному рядку з додатком можна вказати скільки процесорів використовувати. Диспетчеру підтримуваного таку можливість можна описати такі правила для кожного типу сервісів (додатків). Тоді він сам може змінювати "вага" підзадачі для того щоб краще заповнити вільне місце вважає комп'ютера. Це має сенс тільки якщо диспетчер підтримує попередній пункт (Multi Task Host).
Multi Host Task:
Деякі додатки можуть запускатися на декількох комп'ютерах одночасно, так би мовити підтримують можливість "распараллелівать" самі. Тоді щоб диспетчер їх остаточно :) "допараллеліл", він теж повинен вміти виділити однієї подзадаче відразу кілька клієнтів. З відомих мені програм це підтримують: "RenderMan NET Render", "Mantra Multi Host Render", "Houdini 10 Fluids".
Task Output Parsing:
Спосіб парсинга stdoutstderr підзадачі в основному для видачі прогресу. Кращий спосіб це інстанісірованіе пітоновского класу, який ви самі зробили. Пітон це мова програмування, а значить гнучкість. Клас це не тільки функції але і дані, а значить ви можете зберігати в ньому щось корисне. У класів є успадкування - ви можете написати основні базові парсери, а потім наслідувати від них більш складні.