Top
Deadline Navigation
Deadline Documentation
Thinkblog
RSS< Twitter< etc

How Deadline Works


The Deadline Repository

The Deadline Repository is the heart of Deadline. It stores all the information that is used by Deadline, such as render jobs, slave settings, and software plug-ins. All job scheduling and management is done by reading and writing files to Repository. Deadline's unique architecture allows it to run without the need for a server application, as the Deadline applications can scan the Repository for render jobs themselves. The absence of a server application improves Deadline's robustness because it removes a single point of failure. As long as your Repository share is available, Deadline will be fully functional.

However, if you have more than 50 render nodes in your farm, or are experiencing performance issues, we recommend that you run the Deadline Pulse application on one of your machines in your network. Pulse is included in the Client Installation. Pulse acts as a proxy between the Deadline applications and the Repository, which helps to reduce the load on your network and improve Deadline's overall performance. Note that if the Pulse application goes down for any reason, the Deadline applications will revert back to scanning the Repository themselves. Whether you decide to run Pulse or not, you will still benefit from Deadline's robustness.

When a user submits a rendering job to Deadline, a new job folder is created in the Repository along with the necessary files to store the job's settings. When a Slave picks up the job for rendering, it copies the job folder locally before proceeding. When rendering is complete, the local folder is deleted and the Slave moves on to find another job. Note that all external references the job relies on, such as textures or other scene data, should be network accessible because these files are not copied to the Repository. In addition, rendering output is not saved to the Repository, so the Slaves need to be able to access the job's output path(s) so that the images can be saved. This is explained further in the Render Farm Considerations documentation.

The Deadline Job

As explained above, when a job is submitted to Deadline, it is placed in the Repository where it becomes visible to Deadline Monitor and accessible to the computers running the Deadline Slave application. Most jobs can be broken down into several tasks that make up that job. For example, when rendering an animation with 3ds Max, each frame can be rendered as a separate task. This allows multiple Slaves to be able to work on the same job at the same time. Some other jobs cannot be divided into tasks this way, such as creating a Quicktime movie from the individual frames of an animation.

There are several states that a job can be in during its lifetime in the Repository. The possible job states are:

  • Queued: Job is waiting to be rendered.
  • Active: One or more of the job's tasks are currently being rendered.
  • Suspended: The job is paused, and will not be rendered until it is resumed.
  • Pending: The job is either scheduled, or is dependent on another job.
  • Completed: All of the job's tasks have finished rendering.
  • Failed: The job has reported the maximum number of errors allowed.
  • Archived: The job can no longer be modified.
  • Deleted: The job no longer exists in the Repository.

Below are some examples of the possible paths a job can follow. For information on how a slave actually selects a job, see the Job Scheduling section of the manual.

Normal Job Flow

  1. The job is submitted to Deadline and placed in the Repository. It will have the status of Queued when viewed from the Monitor.
  2. The job is picked up by one or more Slaves. It will have the status of Active in the Monitor. The number in brackets beside the Active status indicates the number of slaves currently rendering the active job.
  3. All of the job's tasks have finished rendering. It will have the status of Completed in the Monitor.

Pending Job Flow

  1. The job is submitted to Deadline that is dependent on another job. It will have the status of Pending when viewed from the Monitor.
  2. The other job that this job is dependent on finishes. It will have the status of Queued when viewed from the Monitor.
  3. The job is picked up by one or more Slaves. It will have the status of Active in the Monitor. The number in brackets beside the Active status indicates the number of slaves currently rendering the active job.
  4. All of the job's tasks have finished rendering. It will have the status of Completed in the Monitor.

Suspended Job Flow

  1. The job is submitted to Deadline and placed in the Repository. It will have the status of Queued when viewed from the Monitor.
  2. The job is picked up by one or more Slaves. It will have the status of Active in the Monitor. The number in brackets beside the Active status indicates the number of slaves currently rendering the active job.
  3. The job is suspended by right-clicking on the job in Monitor and selecting Suspend Job. It will have the status of Suspended when viewed from the Monitor. While a job is suspended, the Slaves will effectively ignore it and not choose any tasks associated with that job.
  4. The job is resumed by right-clicking on the job in the Monitor and selecting Resume Job. It will have the status of Queued when viewed from the Monitor. It will eventually enter the Active state when Slaves begin rendering the job again.
  5. All of the job's tasks have finished rendering. It will have the status of Completed in the Monitor.

Failed Job Flow

  1. The job is submitted to Deadline and placed in the Repository. It will have the status of Queued when viewed from the Monitor.
  2. The job is picked up by one or more Slaves. It will have the status of Active in the Monitor. The number in brackets beside the Active status indicates the number of slaves currently rendering the active job.
  3. The job reports the maximum number of errors allowed. It will have the status of Failed when viewed from the Monitor. While a job is in the Failed state, the Slaves will effectively ignore it and not choose any tasks associated with that job.
  4. The job is resumed by right-clicking on the job in the Monitor and selecting Resume Failed Job. It will have the status of Queued when viewed from the Monitor. It will eventually enter the Active state when Slaves beging rendering the job again.
  5. All of the job's tasks have finished rendering. It will have the status of Completed in the Monitor.

Requeued Job Flow

  1. The job is submitted to Deadline and placed in the Repository. It will have the status of Queued when viewed from the Monitor.
  2. The job is picked up by one or more Slaves. It will have the status of Active in the Monitor. The number in brackets beside the Active status indicates the number of slaves currently rendering the active job.
  3. All of the job's tasks have finished rendering. It will have the status of Completed in the Monitor.
  4. One or more of the job's tasks are requeued by right-clicking the tasks in the Monitor and selecting Requeue Tasks. One reason to requeue a task is that its rendered output may not be satisfactory (the software on a Slave may be misconfigured, for instance). It will have the status of Queued when viewed from the Monitor. It will eventually enter the Active state when Slaves beging rendering the job again.

Archived Job Flow

  1. The job is submitted to Deadline and placed in the Repository. It will have the status of Queued when viewed from the Monitor.
  2. The job is picked up by one or more Slaves. It will have the status of Active in the Monitor. The number in brackets beside the Active status indicates the number of slaves currently rendering the active job.
  3. All of the job's tasks have finished rendering. It will have the status of Completed in the Monitor.
  4. The job is archived by right-clicking on the job in the Monitor and selecting Archive Job. It will have the status of Archived when viewed from the Monitor. Archived jobs cannot have their status or properties changed, but you can still explore their output or retrieve the data file submitted with the job.