Need some help from the Techies

[dj_buckley]

So I've just added a 3990x to my arsenal.

As things stand I currently have 3 boxes

Xeons Box - E5 2640 v3 (x2) - this is old
i9 Box - i9 7980XE
Threadripper box - 3990x

I've just tested a quick scene.

Before today I was working on the i9 Box and sending DR renders with the Xeons joining in.

So here are my rendertimes.

i9 on it's own - 19 mins 9 seconds

i9 with Xeons DR - 13 mins 40 seconds

i9 with Xeons and Threadripper DR - 9 mins and 36 seconds

i9 with Threadripper DR - 10 mins and 49 seconds

I then fired up the scene locally on the Threadripper and it rendered in 8 mins and 34 seconds.

The Threadripper on it's own was the fastest option.  I don't understand.  Has adding the Threadripper just made my other two machines completely redundant in terms of rendering?  Is it that fast that the other 2 are hindering its capabilities?  Or have I got a problem somewhere?  Network maybe?

[MattiasD]

I`m not sure if I`m right, but when starting DR the scene gets saved and sent to the other machines. Then max has to fire up and load the scene on the nodes. So depending on your scene size/complexity/... this might take some time. Also bare in mind that the sending to the other nodes is a sequential process, so depending on your scene size and network speed, this might take some time too.

[dj_buckley]

For sure.  I'm just amazed that it's so quick that it's more efficient to leave the older boxes out of the rendering altogether

[maru]

How exactly did you measure the render times? What kind of limit was used here?

[dj_buckley]

All to 2.5 Noise Threshold.

It was all done from the same machine (the i9) jus ticking off and on the boxes for all the different combinations and rerendering

Apart from the local TR render where I opened it on the TR and did a local render

[maru]

All to 2.5 Noise Threshold.

This could be the reason. Noise level is calculated differently for different parts of the image, and also it is re-calculated every 5 passes, and updating/collecting the images from slaves takes some time... So all in all it may not be a very reliable measuring method.
I *think* rendering to a pass limit could be a better solution. Especially to some higher number like 100 or more, in high resolution (1080 px or more).

[dj_buckley]

I'll give it a go.  It was rendered at 5k pixels though.  The issue I have with anything other than noise threshold is its just pure guesswork.

To few passes and it might be too noisy, too many passes and it could be wasted render time

[maru]

5k, 2.5 nois limit, and just 8 minutes? That's weird. The scene must have been super simple, or there was a lot of sky or other solid color visible. That probably didn't render many passes, which makes the experiment even less trusty.

[dj_buckley]

Yep, was a super simple scene.  I'd assumed the test would be relative for more complex jobs

[dj_buckley]

i mean, that's my usual setup for final renders.  So I don't think it's unreasonable to assume that rendering it as per I normally would, noting down the time, then doing the same but with the TR added and comparing the difference, is a decent way of comparing the speed increase?

[TomG]

It's a reasonable way to find how things will change with your particular workflow, for sure. Overall though, DR may not be having a chance to contribute much, and the overhead of sending the scene, swapping data back and forth, etc. may be why DR doesn't help with your particular workflow. Which is different from testing how DR can contribute in general, but of course, if this is how most of your scenes are set up, then it is important to know how DR changes your results in those particular set ups :)

[dj_buckley]

Cool.  Back to the original point though and to summarise.  The TR is absolutely lighting quick, it just so happens this scene isn't the best for testing as its too simplistic and I'll really see the benefits on a more complex scene.  I think everyone has kinda answered my question that I don't have a problem as such, just needs a more 'testing' test.