Search TipsUsing the Frame Server on External Machines
Although Hiero is capable of rendering frames internally, running the Frame Server on an external machine can accelerate the process considerably by sharing work across a network of machines.
Note: The Frame Server requires a Hiero license (hiero_i) on the main workstation, but only a Nuke render license (nuke_r) on the worker machines. Local Frame Server processes use ports 5558-5662.
If you want to use an interactive license (hiero_i) on the worker machines, add the --useInteractiveLicense argument to the runframeserver.py command described below.
Configuring the Frame Server on External Machines
Hiero's Frame Server can be set up on an external machine (or a number of machines) to render from your Hiero session. To do this, you need to run the runframeserver.py script on the external machines, found inside the Python site-packages, with specific command line arguments.
Warning: In order for everything to work smoothly, you need to ensure that both your external worker machines and main Hiero session can read and write files to a shared location, such as an NFS share.
Depending on platform this can be done by manipulating your default umask setting, but be aware that this alters the permissions of the created files.
Additionally, Mac and certain Linux distributions, such as RHEL, can not function as the main workstation if the firewall is blocking the communication port 5560. You can configure the firewall to allow certain ports through the firewall using the iptables command, but use caution when doing so. For example:
sudo iptables -I INPUT -p tcp --dport 5560 --syn -j ACCEPT
Please refer to the documentation on firewalls for your particular platform for more information.
The Frame Server uses a number of worker processes on the external machine, each of which requires allocated resources, such as threads, memory, and so on. There are a number of arguments that you must pass to runframeserver.py for the server to work correctly:
• --numworkers - this is the number of concurrent processes that are launched when you run this server render node.
• --nukeworkerthreads - the number of threads that each worker is allocated. This is similar to setting the -m argument when running the application from the command line.
• --nukeworkermemory - the amount of memory, in MB, allocated to each frame server worker.
• --workerconnecturl - the TCP port address of the main workstation you want to serve. For example:
tcp://bob:5560
where bob is the resolved hostname of a machine you wish to serve. You can also use an IP address.
Tip: To ensure that you're entering a valid URL, try using the ping command to see if you get a response.
• --nukepath - the path to the application on the worker workstation.
Tip: On Windows, if there are spaces in the file path, remember to place the path in quotes.
For example, --nukepath="C:\Program Files\Nuke12.2v10\Nuke12.2.exe"
On a Linux worker machine, an example command prompt entry running from the install directory might look like this:
./python ./pythonextensions/site-packages/foundry/frameserver/nuke/runframeserver.py --numworkers=2 --nukeworkerthreads=4 --nukeworkermemory=8096 --workerconnecturl=tcp://bob:5560 --nukepath=./Nuke12.2
On a Windows worker machine, an example command prompt entry running from the install directory might look like this:
python.exe pythonextensions\site-packages\foundry\frameserver\nuke\runframeserver.py --numworkers=2 --nukeworkerthreads=4 --nukeworkermemory=8096 --workerconnecturl=tcp://bob:5560 --nukepath=Nuke12.2.exe
In the examples, we specify that the render uses two workers, with four threads and 8 GB RAM each, and are clients to the main Hiero workstation running on bob.
Tip: If your worker machines run a different OS than your main Hiero machine, you can use the --remap command line argument to convert file paths between them. The host file path is read first followed by the worker file path. Hiero expects all file paths to use / (forward slash) between directories. For example:
--remap "P:/,/mnt/renders/"
converts host paths beginning with P:/ (Windows style) to worker paths beginning with /mnt/renders/ (Linux style).
You can check that the Frame Server and workers are connected by running the following lines in the Script Editor on the main workstation:
from hiero.ui.nuke_bridge.FnNsFrameServer import frameServer
print [worker.address for worker in frameServer.getStatus(1).workerStatus]
Successful connections should report something similar to the following in the output panel:
['Worker 0 - henry.local - 192.168.1.11', 'Worker 0 - bob.local - 192.168.1.111', 'Worker 1 - henry.local - 192.168.1.11']
Where henry.local is the name of the remote worker, and bob.local is the name of the main Hiero session.
Note: If the workers cannot contact the Frame Server, an exception is printed in the Script Editor's output panel.
Frame Server Logs
Broker and Worker logging can to help diagnose Frame Server issues. The logs are written to NUKE_TEMP_DIR/logs by default, and take the form:
broker.log
worker-0.log
worker-1.log
worker-2.log
Note: Running the Frame Server using Python, as described above, always writes log files to the specific OS temporary directory. For example, on Windows C:\temp is used.
Tip: You can use the FRAMESERVER_LOG_DIR environment variable to force Frame Server logs into a different location. See Environment Variables in the Nuke Online Help for more information.