* All managers parameters are were collected at 2009.06.15 and may be changed.

 Name 

      Price      

Annual
Support
and Upgrade

Engine

Other
Tools

      OS      

Job
Submission

Storage

 Host Resources 

  Comment                                                                               

SQL statistics*

SQL statistics*

(+SQL**)

 Name 

      Price      

Annual
Support
and Upgrade

Engine

Other
Tools

      OS      

Job
Submission

Storage

 Host Resources 

  Comment                                                                               

* All managers parameters are were collected at 2009.06.15 and may be changed.

Price:
Product price at 2009.06.15. See links for current prices.
Often depends on quantity of render nodes in your farm - how much clients can be connected to server. Its better when application can be launched and checked with one or several clients for free.

Engine:
typed - Command lines are generated by manager itself, depending on job type (Maya, Nuke, Houdini, RenderMan, e.t.c) and job settings like first and last frame, resolution, camera e.t.c. Most "ready" way
cmd+numbers - Command lines are generated by filling some pattern with numbers (frames). Most "cheap" way. Usually client run a process with environment variables pointing on first and last frame to render, and your command may use them. (But how to split, for example, shadows ?).
cmd array - Each job task has a command line. Most "customizable" way. You can do anything you want (you can do IS, IC, LR (see below) by writing you own "smart" commands and utilities).

Other tools:
Various tools, not directly related to tasks distribution. Better to do all this things yourself (admins, TDs can automate it) for full control, not by manager additional utilities or even engine. But it can be useful for small companies without TD.
UP - Manager application update utilities (admins can do it in their favorite way).
NM - Network drive mapping for MS Windows (better to use UNC paths).
IS - Image splitting (slicing) or "Tile Render" (may be your application or image format are not supported).
IC - Image checking. Often it is an ability to check existence and minimum size of specified files.
RC - Copy scene local resources (wow :) TDs must care about resources location and movement, not users).
LR - Local Render - render images locally and copy to final network location them after render complete. Can save network traffic (better to copy image once, not writing small portions during calculation).
PM - Power Management - Server can shutdown clients if they are not busy for some time. May save electricity.
Remember, Alfred with no tools, more popular in big and famous companies. No matter what manager can already do. Matter to be flexible to be able to learn to do anything, like a constructor.

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.

Job Submission:
The way to submit a job. Better to have some methods without any GUI to integrate in your working program in best way. Command line utility is the simplest way. Script is most flexible way, but will your write it yourself? You'll generate it in your application script. Python integrated in most popular CG programs, such as Houdini, Maya, Nuke. It is very comfortable to communicate and scene and manager within the same script.
GUI - some special dialog to fill with values to submit a job.
cmd - program which can submit a job parsing arguments.
Integration with your working program can help you to integrate manager in your scene. For example in Nuke and Houdini there must be a node to generate and send jobs, not a dialog. This node you can connect with others, write expressions on its parameters.

Store:
The way manager stores jobs and may be other settings. No store means jobs loss on server restart. SQL is a standard way to store data, you can connect database your own way and make any unique queries you want (for example write Python or PHP scripts for you own utilities).

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.

Job Dep:
Job dependence. Job can wait other job(s) to be done to run. Very useful, as result of one jobs can be sources for others.
f - Whole job can be frame depending or not. If job is frame depending each its frame waits other job same frame. May be useful for managers without tasks dependence.

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.

Several Clients Same Host:
An ability to launch more than one clients on the same host. It is the simplest way to make host to render more tasks at the same time. Also another client may have its own configuration, for special purposes. Useful for comfortable debug, or simple check something new.

Multi Task Host:
One client can run several tasks at the same time. Useful for farm with hosts and tasks with different "power". More powerful machine can run more tasks. More lite tasks can be executed on the same machine. More balanced farm resources usage. No time wasting (time wasting may happen when client run some lite task which take no resources, but can't do to something else simultaneity, as server interpret it as "busy" or "free" only, server does not understand how much client busy).

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 (stdout&stderr). 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.

Сравнение Менеджеров Рендер Фермы.

Price:
Цена на 2009.06.15. Уточняйте текущие цены по ссылкам.
Зачастую цена зависит от размера вашей фермы - количества компьютеров в ней, а точнее от количества клиентов, которые могут подключиться к серверу (или репозиторию в случае с DeadLine). Большой плюс, я считаю, когда менеджер можно попробовать бесплатно с несколькими клиентами, так вы получите полное впечатление перед покупкой (ну или раздумаете покупать).

Engine:
"Движок" или кто генерит команды.
typed - Командные строки генерит сам менеджер, в зависимости от типа задачи (Maya, Nuke, Houdini, RenderMan, e.t.c), начального и конечного кадров, а также всевозможных параметров типа разрешения, камеры и прочих справедливых для данного типа (рабочей программы). Обычно это наиболее "готовое" решение. Вы сразу же можете делать всё, что может данный менеджер. Но зато его наиболее сложно приспосабливать под уникальные для фирмы (проекта) задачи. И вообще не факт что под вашу задачу его вообще можно приспособить. Подходит больше для мелких фирм без администратора, технического директора, разработчиков, и делающих более "однообразную" работу используя для этого известные готовые решения и распространённые программы.
cmd+numbers - Командные строки для разных кадров генерятся из одной путём подставления в неё начального и конечного кадра. Это очень "дешевый" способ, просто администрировать/программировать, мало трафика и вообще мало данных на задачу. Но не понятно как посчитать задачу если она разбивается не на кадры (к примеру тени). Обычно процесс запускается просто с переменными окружения (environment variables) указывающими на начальный и конечный кадры, а вы должны сделать такую команду которая бы из как-то использовала. Но есть и другие решения.
cmd array - Каждая подзадача имеет свою командную строку. Наиболее "гибкое" решение. Вы можете делать всё что хотите.

Other tools:
Всевозможные инструменты, не имеющие прямого отношения к управлению фермой. Они не обязательно должны поставляться вместе с менеджеров и уж тем более быть зашитыми в его движок. Их можно сделать самим и прикрутить к вашему менеджеру, более того так даже лучше, так вы будете их контролировать. Но для маленькой конторы без админов наличие таких утилит может помочь, если они справятся с вашими задачами.
UP - Утилита как-то автоматизирующая апдейт всех клиентов на ферме. Если в фирме есть админ, то он и так всё апдейтит как ему это удобно. Может имеет смысл если его нет.
NM - Автоматический "маппинг" не существующего сетевого диска в MS Windows. Лучше пользоваться не сетевыми дисками а UNC путями. В документациях к диспетчерам, поддерживающих такую возможность так и написано.
IS - Image splitting (slicing) or "Tile Render" - разбиение картинки на части и одновременный их рендер на разных компьютерах. Но не факт что такой диспетчер справится с нужным вам форматом и вообще умеет это для нужной вам программы. Обычно это громкие слова в "Features" и подробное описание условий как, где и для чего это всё же работает. Лучше делать это самим и полностью контролировать этот процесс.
IC - Image Checking - возможность проверить картинку на "битость" (обычно это минимальный размер файла). Вот это может быть полезно для особых случаев, но обычно если процесс завершился без ошибки то и результатом всё хорошо. А если у вас особые случаи, то лучше и делать всё самим.
RC - Resources Copy - Копирование локальных ресурсов на файловый сервер. Администраторы и ТД должны заботиться о месте хранения и копировании ресурсов, а не пользователи. Где не так там бардак и сеть вечно тормозит.
LR - Local Render - рендерит картинку локально, а затем копирует её на место в общее сетевой ресурс. Экономия сетевого трафика, так как лучше один раз переписать весь файл, чем постоянно по чуть-чуть дописывать во время просчёта.
PM - Power Management - Сервер может выключать рендера когда они какое-то время стоят без дела, а потом опять включить. Экономьте электричество :)

Помните, Alfred, который вообще без "утилит", наиболее распространён в крупных конторах как у "нас" так и у "них". Не важно что уже умеет делать диспетчер, важно чтобы его можно было научить чему угодно. Как конструктор.

OS:
Под какую операционную систему существует программа или её часть - сервер, интерфейс, клиент.

Main Server:
Наличия главного сервера у диспетчера. Как это не странно может показаться подкованному человеку, но у некоторых диспетчеров его нет. Это может привести к неудобству его администрирования. Например невозможно на время кому-то что-то запретить или управлять чужой задачей.

Job Submission:
Способ постановки задачи. Хорошо если есть способ без каких-либо графических приложений (диалогов GUI) для интеграции в вашу рабочую программу. Консольная (командная) утилита - самый простой способ. Скрипт наиболее гибкий способ. Но кто будет писать его руками? Он всё равно будет генериться какой-либо утилитой. Python интегрирован во многие популярные CG программы, такие как Houdini, Maya, Nuke. Очень удобно общаться и со сценой и с диспетчером внутри одного скрипта.
GUI - Диалог, в отдельном приложении или вызывается из монитора менеджера.
cmd - консольное приложение, которое может сгенерить задачу из командной строки и послать на её сервер.
Интеграция с вашей рабочей программой может оказаться очень полезной. Вы можете перенести идеологию вашей программы и интегрировать диспетчер в сцену. Например в Nuke и Houdini должна быть именно нода, посылающая задачу, а не какое-нибудь окошко диалог, которое рушит их принципы. А это на эту ноду тогда уже можно с чем-то конектить, писать экспрешены.

Store:
Способ долговременного хранения данных. Если его вообще нет и данные хранятся только в памяти сервера, то в случае его перезапуска они будут утеряны. Самый стандартный способ хранения вообще каких-либо данных - база данных SQL. В этом случае, ознакомившись со схемой их хранения, вы сами можете их читать и обрабатывать как угодно. Писать для этого собственные утилиты, не зависящие от разработчиков сервера, от его протоколов.

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:
Способ парсинга stdout&stderr подзадачи в основном для выдачи прогресса. Лучший способ это инстанисирование питоновского класса, который вы сами сделали. Питон это язык программирования, а значит гибкость. Класс это не только функции но и данные, а значит вы можете хранить в нём что-то полезное. У классов есть наследование - вы можете написать основные базовые парсеры, а потом наследовать от них более сложные.