Distributed renderings relay on the network for any kind of data transmission. That’s a good reason to consider your network physical layer as the primary bottleneck in the entire rendering process.
As a network administrator, you can follow several steps to ensure your network is working at its maximum capabilities and modify your settings and topology to increase performances.
This section gives some hints that may apply in a common environment. Every network environment has its own characteristics that should be analyzed according.
Priority 1: Your file repository: As explained in the tutorial, files that are going to be processed by multiple hosts must have visibility over the network in a common way. Building a shared file repository is the first step you’ve to take into account. There’re several ways to accomplish it, you can choose either a NAS or a server depending on your budget limits; just make sure that you do not impose any concurrent connection limit, like it may happens when sharing files on a Windows XP system. The Windows XP system isn’t designed to act as a file server and the default Microsoft policy is to limit the concurrent connections to a maximum of 5. This is a common pitfall of new users that are not aware of such kind of limit and get back strange results, process hangings and similar. A good solution could be moving to a Linux system using the Samba service and/or install a Windows server operating system with enough client licenses. Again this strongly depends on your budget and your existent network topology.
Priority 2: Connections to the dispatcher server: The Dispatcher service should be considered as something different than the file repository. Even the service can be installed on the same machine, it performs a different task. The purpose of the Dispatcher is controlling the remote hosts using low bandwidth messages. When applicable, the Dispatcher server should have a privileged connection to the rendering hosts or at least, separate the corporate network traffic. An optimal setup could be made by several routers routing different packets across different network interface cards on both the server and the clients. Having an high number of clients talking with the Dispatcher for both controlling and I/O messages could increase the latency of the transmission itself, wasting precious seconds of unused calculation waiting for incoming commands.
Priority 3: Cross-platform: When using different operating systems, you should take into account the issues deriving from shares mount points. The substitution paths tool in Muster helps you exchanging the paths but a good planning of your shares is something you should take into account in the initial farm design.