##
Render Farm Menu and Parameter Description

Below we describe the Performance tab for configuring a render farm (figure 7.11).

Figure 7.11: Settings: Preferences: Performance tab, menu to set up your Render Farm

Project SMP cpus
  although this field is not Render Farm specific, it is useful for CINELERRA-GG to have the CPU count and for using multiple threads.
Use render farm
  check this to turn on the render farm option. Once checked ALL rendering will be done via the farm including the usual Render (Shift-R). You may want to turn if off for small jobs.
Nodes listbox
  displays all the nodes on the render farm and shows which ones are currently enabled. The Nodes listbox has 4 columns – On, Hostname, Port, Framerate – which show the current values. An X in the On designates that that host is currently enabled; Hostname shows the name of the host; Port shows the port number that host uses; and Framerate will either be zero initially or the current framerate value.
Hostname
  this field is used to edit the hostname of an existing node or enter a new node.
Port
  keyin the port number of an existing or new node here. You can also type in a range of port numbers using a hyphen, for example 10650 - 10799 when you need to add many.
Apply Changes
  this will allow you to edit an existing node and to then commit the changes to hostname and port. The changes will not be committed if you do not click the OK button.
Add Nodes
  Create a new node with the hostname and port settings.
Sort nodes
  sorts the nodes list based on the hostname.
Delete Nodes
  deletes whatever node is highlighted in the nodes list. You can highlight several at once to have them all deleted.
Client Watchdog Timeout
  a default value of 15 seconds is used here and the tumbler increments by 15 seconds. A value of 0 (zero) disables the watchdog so that if you have a slow client, it will not kill the render job while waiting for that client to respond.
Total jobs to create
  determines the number of jobs to dispatch to the render farm. Total jobs is used to divide a render job into that specified number of tasks. Each background job is assigned a timeline segment to process. The render farm software tries to process all of the rendering in parallel so that several computers can be used to render the results. You should adjust this for each different video if your work varies considerably in time so that each task time is not too small.

  To start, if you have computers of similar speed, a good number for Total jobs to create is the number of computers multiplied by 3. You will want to adjust this according to the capabilities of your computers and after viewing the framerates. Multiply them by 1 to have one job dispatched for every node. If you have 10 client nodes and one master node, specify 33 to have a well balanced render farm.

(overridden if new file at each label is checked)
  instead of the number of jobs being set to Total jobs to create, there will be a job created for each labeled section. If in the render menu, the option Create new file at each label is selected when no labels exist, only one job will be created. It may be quite advantageous to set labels at certain points in the video to ensure that a key portion of the video will not be split into two different jobs.
Reset rates
  sets the framerate for all the nodes to 0. Frame rates are used to scale job sizes based on CPU speed of the node. Frame rates are calculated only when render farm is enabled.

Framerates can really affect how the Render Farm works. The first time you use the render farm all of the rates are displayed as 0 in the Settings → Preferences, Performance tab in the Nodes box. As rendering occurs, all of the nodes send back framerate values to the master node and the preferences page is updated with these values. A rate accumulates based on speed. Once all nodes have a rate of non-zero, the program gives out less work to lower rated nodes in an effort to make the total time for the render to be almost constant. Initially, when the framerate scaling values are zero, the program just uses package length – render size divided by the number of packages to portion out the work (if not labels). If something goes wrong or the rates become suspect, then all of the rest of the work will be dumped into the last job. When this happens, you really should reset rates for the next render farm session to restart with a good balance.

    {path_to_cinelerra}/cin -h  # displays some of the options.