At Jigsaw we’re frequently asked by customers, “What’s the most important facet of a render farm – memory, processor speed or access to storage when it comes to 3D rendering?” Unfortunately this question doesn’t have a simple answer – the best way to explain is to use a metaphor:
In a restaurant’s takeaway delivery service, what is the key factor influencing our appraisal of the service? How quickly the chef prepares and cooks the food? The efficiency of the person taking orders over the phone? The time it takes the guy on his moped to deliver the food? How about the quality of the food?!
Obviously, there is no one clear answer. We haven’t considered the different types of food on offer, the distance it needs to be delivered, the number of inbound order calls, or even if the guy taking the calls has to write them by hand or has an automated electronic system. We don’t know how many grills the restaurant has, how long it takes to cook each dish, or if there is a pattern for ordering. It becomes very clear that the answer is usually “It depends,” and the conditions that it depends on are nothing if not dynamic.
To relate this to 3D rendering, simply replace “chef” with “processor”, the person taking orders with “memory” and the delivery guy with “shared storage”. Now you have a render farm scenario.
Just like the example of the takeaway restaurant, in order to get a specific answer to the question about your 3D render farm, your query itself needs to be much more specific.
The question should be “what’s the most important element in a render farmrunning ABC 3D application,” not simply “what’s the most important element in a 3D render farm.” After all, one chef could churn out edible dishes every few minutes while another could be doing no better than one every 10 minutes because he works more methodically and presents dishes of a higher standard.
The answer lies in recognising and measuring what the key bottlenecks are when performing your job:
How long does it take to render a given jog unit (e.g.10 frames) on a given processor with your 3D software application of choice?
– What is the volume of data going into the image and how long does its take to retrieve this data from the drive?
– How reliant on memory speed is the rendered frames’ delivery?
– What is the time frame on delivering your frames to a designated drive?
Once these have been answered for one system (processor/memory chip/shared drive) we can start to think about the render farm as a whole. What starts happening to our render performance if we add more processors, memory storage or speed? Or in terms of our takeaway analogy, what happens if we add more people to take orders, more chefs to cook the food, or more people on the phones to take more orders and to prioritise jobs?
We have to be careful at this stage to try to keep all parts of the farm balanced. For example, you don’t want to be in a situation where all jobs are coming in too quickly for processors to handle but, on the flip-side, we don’t want jobs being processed so fast that the storage can’t read and write frames fast enough.
If we look at this sensibly, we’ve already established roughly how long it will take each processor to get its next set of instructions, render 10 frames and then save them to a location. Using these figures, we can estimate capacities and rates, allowing us to work out the best way to spend our money.
Render farms are usually CPU bound, processing large amounts of work compared to the data coming in, so fast I/O is often a good thing. A large cache can also be beneficial, depending on the size of the frames being rendered.
With data transfer rates at the speed they are, it’s unlikely that SAN speed will be the first bottleneck but this is very dependent on the size of the render farm. For example, there will become a point where there will be too many nodes rendering in parallel, resulting in the processors waiting on the storage. At this stage, things start to depend on how big the image is, how long it takes to render a frame, and if frame completions are synchronised.