How to estimate size/benefit ratio for DR renderfarm

[simmsimaging]

Hi -
I'm looking at building a larger (for me) farm for DR renders for stills. I don't use Backburner, just DR as it seems to be all I need.

I need to get an idea how many machines/cores I want to add but I can't figure out how to even roughly gauge the speed increase over the number of cores so I can find the optimum performance versus price ratio for me. Is there some way to figure it out as a percentage per core, or some other measuring stick? I'm sure more is always better, but there must be a point of diminishing returns and I want to avoid leaping right over it. Budget is limited and I don't want to spend 40% more money for a 4% gain etc. I'd rather spend the extra dough on video games or something to keep me occupied while I wait for the renders

I only have 3 boxes here and each one is very different so I can't really test it in-house to see how it might scale.

Any tips would be appreciated.

Thanks
b

[Morne]

I had the same problem a few months ago. I was also faced with well should I get one hell of a beast machine or just get something normal people would buy and then add a couple of render nodes. I opted for a normal pc with couple of nodes. It worked out far cheaper and I'm very happy with my choice. The price of one huge machine would have cost almost 3 times the price and end up having less "total render power" than my small dr farm. Plus now I use backburner (something I thought I would never touch) so I can render and free up a pc or 2 for other stuff. Anything quadcore or better is usefull, Dual core is just a waste of money. I'm running Intel Q9550 with 8gb ram as my workstation with a ATI HD 2700 XT and it works perfectly well for what I do. These last few weeks I've been doing huge demanding scenes and the system handles it farely well.

Good luck!

[simmsimaging]

Thanks for the input. I agree it's going to be cheaper to span it over a number of machines, but I'm still trying to find a way to get a more precise handle on the cores to speed ratio and how it scales/drops off etc. I think I'll go with several less 'killer' render nodes - the question is how many?

b

[simmsimaging]

Okay - usually a lack of answers means I asked a dumb question or one that has been asked too many times, but I have spent another hour or so digging through the forum and still can't find it

Is there some way to gauge the speed increase over number of nodes/cores or does anyone have a link on this that they could post?

thanks!
b

[RErender]

In this case I'd say the lack of answers is more due to nobody knowing the answer.

Anecdotally, many people have gotten good results with 10 or more slaves working together in DR. As long as your storage systems and network are relatively fast then it should handle what you throw at it. Where exactly the benefit of adding more slaves becomes nil is a hard one to figure, the limit I guess would be the time needed to distribute the data across the network. Based on that I'd probably tend towards fewer, more powerful boxes.

[simmsimaging]

Thanks Eric.

b

[simmsimaging]

Vlado - would there be any way to figure out an answer to this question without testing on a farm? Testing is not a real option for me, at least until it's too late

Thanks
b

[devin]

About 4 years back when we first started using DR we tested what the speed increase was starting with my main work station and then adding 4 DR nodes. I've attached a graph showing what the benefits of each machine being added were. As you can see the first few machines really makes a difference but the more you add the less benefit you actually get. Of course the kind of network you have and the way you set up your mapped files can make a difference in how long it takes to send and load your scene onto your DR machines. At the time we were using a 1gigabit setup but it wasn’t optimized as the data had to go through several switches and servers before it made it to the DR machines. Today I'd expect these numbers to be better as the DR process has improved, but I think the graph will still look something like this. If I have time I'll test it to see if this is indeed still the case.

[simmsimaging]

Thanks for sharing that. I would definitely be interested in hearing if that is a typical fall-off of performance. I can kind of see how it might be, but it does seem pretty rapid too. Appreciate the post!

b

[RErender]

I wonder though if the graph just shows that it took about 2 mins to distribute the scene around the network, I would guess that if the test took an hour to render, significant gains would be seen by adding even more nodes, so average render times would have to be factored in to find the ideal node ratio.

[simmsimaging]

Good point - did not consider the overall time factor. It is a very short render by my standards

b

[devin]

I believe that RErender is correct, this test shows that in renderings that have short render times having lots of DR machines doesn’t help because it takes a while for everything to load and rendering by comparison takes very little time. In scenes that are very large and take hours having lots of DR machines will make a significant difference.

I'm on vacation right now but when I get back I'll redo the test to reflect a more complex and higher resolution scene.

[dlparisi]

Somewhat related to the time of the rendering is the size of the buckets. A lot of very small buckets (say 16x16) will render slower than the standard bucket size (64x64) due to overlap or something like that. I believe for speed you'd want to have as few buckets as possible, essentially one bucket per available processing core. This is assuming all of your machines have comparable speed-otherwise smaller buckets will balance the load better between the machines.

It's not really a clear cut answer in my book, just what works best for you and your situation.

[simmsimaging]

dlparisi: Thanks, I did try some changes of bucket size but found the results were hit and miss, sometimes faster and sometimes slower.

I'm still trying to figure out this DR scaling thing and Vlado has suggested that it is also scene/setting dependent. I'm wondering if there is anyone out there with a small DR farm of minimum 10 nodes that are all identical boxes, and who would be willing to run a *paid* test for me. I'd like to run a small sample scene with 1 node, 2 nodes, 3 nodes, etc all the way up to 10 nodes, and then compare the times. I'd like to do it with probably two different scenes to see how scene variations might play into it. I would expect and be willing to pay for the time/trouble. If anyone has a suitable small DR farm and might be interested pls email or pm me.

Thanks!
b

[rmejia]

I use DR but not all the computers are the same. I have not run any time tests ... but from my experience using additional computers in DR, the only downside is the initial time it takes to send the scene to the other computers, but once it starts rendering, in theory I think if you have two equal computers, it should render twice as fast (minus the initial time to send the scene). For quick renders, the initial time to send the scene can be big handicap, the noticeable advantage would be for scenes that take hours to render. The initial setup time to me would be the factor limiting the amount of pc's that one should have for the DR, it would be better to have a single 8 core pc rather than 2, 4 core computers. In a perfect world I guess a 16 or 32 core machine would be the ideal DR machines. More cores in 1 pc so the initial time to distribute the scene would be only once or twice, rather than times x number of computers. Of course this is more expensive, which is the downside to having less more powerful computers vs twice as many cheaper computers. Where having a whole lot of cheaper computers would be useful is for animations, where each individual pc can render it's own frame.

Maybe this calculator can be helpful to compare costs and time:
http://www.rebusfarm.com/calculate-costs/index_en.html