TCP/IP group

The two spinners in the TCP/IP group box specify the port numbers to be used by the Manager and Servers. These numbers must be unique, but every Server must have the same number.

Manager Port

Specifies the port number used by the network Manager.

Server Port

Specifies the port number used by the network Server(s).

NotePort numbers are like extensions for different users of the same phone number. They represent two channels of communication between the Server and the Manager. Only a trained network administrator should change these settings.

General group

Max(imum) Concurrent Assignments

Specifies the number of jobs the Manager sends out at once. This number is dependent upon the speed of the processor on the Manager machine, the size of the jobs being sent out, and the speed of the network system. Generally, a default value of 4 is adequate. You may want to decrease the value in case the jobs are huge and you have a modest setup. Similarly, you may want to increase this value if you have a high-end setup and the jobs are small. Be aware that too high a value may result in an increased number of timeouts because the jobs are sent faster than the Servers can handle them. In such a case, decrease the value or leave it at the default.

User Server Limit

Sets the maximum number of servers that will be allocated for a specific job. This feature overrides the server limit settings in the 3ds MaxAdvanced Settings Dialog.

Task Error Limit

Defines the number of times a server will retry a task before suspending the task. This option is available only in the Manager General Properties dialog.

Failed Servers group

This option allows the Manager to automatically restart Servers that have failed jobs.

Restart Failed Servers

Activate to enable automatic Server restarting. If this option is turned off, the Server will not attempt to render the job again after the first failure. Default=on.

Number of Retries

Specifies the number of times the Manager attempts to restart a failed Server. Default=3. Range=1 to 1024.

Seconds Between Retries

The time, in seconds, between each retry. Default=30.

NoteThe state of a Server is kept on a per-job basis. If Restarts Failed Servers is turned on, the Manager keeps track of when a Server fails a particular job. The Manager regularly goes through the list of Servers for that job, checking for failures. If one is found, the Manager checks how long it has been since it failed. If the time elapsed is greater than the specified Seconds Between Retries, the Manager decreases the Number of Retries by one and resets the failed flag from the Server.

If a Server fails repeatedly on a specific job (failures are monitored on a per-job basis), the failure count reaches the specified Number of Retries, and the Manager stops trying to restart that Server for that particular job. If, on the other hand, a Server restarts and completes a frame, it is flagged as active and resumes rendering until the job is complete.

Direct Access To Jobs Path group

Job paths can be useful when dealing with situations where it's not conducive to have jobs placed on the manager system. Such situations might be as follows:

• You have a lack of drive space on the C: drive where Backburner is installed. Drive D: has plenty of space so you set up a folder called MyJobs where jobs will be placed when submitted. Enter a UNC path such as \\machinename\MyJobs.
• You're running a large render farm that causes a lot of network traffic on the manager system that you use concurrently to build models. To alleviate the traffic, you set up a shared job folder, backburnerJobs for example, on a file server that is separate from the manager system. The UNC job path would be set to \\fileserver\backburnerJobs and jobs you submit will be placed on the file server.

Use Jobs Path

Turning on this switch allows you to define the location of jobs to be somewhere other than on the manager machine. This tells the render servers to get the job files from the new location, therefore minimizing the file I/O traffic on the manager.

Win32 Path

Enter the path where jobs are located into this field or click the Browse button to the right to search your system for the job location.

Unix Path

This field functions the same as the Win32 path except you can enter a Unix path structure.

Default Job Handling group

The settings in the Default Job Handling group allow a user to archive a completed job to a specified location after x number of days, delete a completed job after x number of days or just leave the job indefinitely in the queue.

Using these controls lets you maintain the job queue, clearing completed jobs that can cause excess overhead and stress to the manager system, thus instigating performance problems. The archiving functionality allows you to automatically store files used for completed jobs.

Do Nothing

When turned on, a completed job is left in the queue.

Use this switch if you are submitting a job that may need to be re-rendered at a higher resolution without making any other changes to the scene.

Delete It

Upon completion, the job is deleted from the queue when this switch is turned on.

If the scene you're rendering is just a test shot and you're just doing a quick test of the scene, you don't really want to keep the job in the queue once it's completed.

Delete After ... Day(s)

Upon completion, the job is kept in the queue for the specified number of days. Once the number of days are exceeded, the job is then deleted from the queue.

Archive It

When turned on, the job is archived when the rendering is complete. Default=on.

Archiving is useful when you submit a final version of the scene and you know that there won't be any further changes.

Archive After ... Day(s)

Upon completion, the job is kept in the queue for the specified number of days. Once the number of days are exceeded, the job is archived.