Network rendering - new 32 core nodes issues

[Hos]

We did some test with multiple renderjobs on one machine at the same time and the results are pretty big.
I took one test I did where the render differences between our old and new renderblades where the biggest and I took one production renderscene.
For the testscene one frame takes 3min38sec to render with all 16 threads.
And 4 of the same frames at once with 4 threads for each frame takes 2 min (30sec per frame) to render.
For the production scene one frame takes 33 min to render and for 4 of the same frames at the same time takes 29 min (7 min for each frame) to render.
That is in both cases almost twice the speed of our old renderblades (x5680)
Maybe this confirms your guess?

greetings,
Arjan

[super gnu]

im assuming that means you have HT off? in which case id be interested to see the same test with HT on!

[vlado]

For the production scene one frame takes 33 min to render and for 4 of the same frames at the same time takes 29 min (7 min for each frame) to render. That is in both cases almost twice the speed of our old renderblades (x5680)

Yep, that's probably closer to the true speed of the machines.

Maybe this confirms your guess?

Only partly; it could be because of either of two reasons and I don't know which one it is... Did you change the process affinity for the separate renders or you just ran them with lower # of threads?

Best regards,
Vlado

[Hos]

Did you change the process affinity for the separate renders or you just ran them with lower # of threads?
Vlado

We used the numThreads flag in the Vray standalone renderer with deadline.

I also forgot to mention that we did the tests with hyperthreading on. But we also did some tests with hyperthreading off but there wasn't that much noticeable difference.

[super gnu]

im surprised you got the same results with and without ht (if those are 16 core machines i guess youd have to double the "numthreads" setting when using ht to see the benefit, or youd only be using 16 threads for all 4 renders still, as opposed to the 32 available. )

in my experience ht usually makes quite a nice difference with vray.

[vlado]

We used the numThreads flag in the Vray standalone renderer with deadline.

Ok, thanks for this info. In that case yes, it looks like it's more as I thought (there is some thread locking in the V-Ray proxy code that can be improved a lot). Still, it might be useful to look into the possibility of running multiple jobs on the servers.

Best regards,
Vlado

[vlado]

Finally got that machine here; as I suspected, there is a part of the V-Ray proxy code that is not well multithreaded. We have a fix for that now - if you are interested, please email me to vlado@chaosgroup.com

Best regards,
Vlado

[jacksc02]

Good stuff Vlado!
Is the update avalible as a total installer package or just an individual file?

[vlado]

It's an installer.

Best regards,
Vlado

[Morbid Angel]

Vlado, what about our case, we do not use proxy, instead just lots of dynamic geometry...and still experience this issue (in maya).

[vlado]

I know... it's a completely different issue in a completely different part of the code and we'll get to that too. However for most of our other tests, performance was close to the expected.

Best regards,
Vlado

[Morbid Angel]

Just curious how many pages of code there is if you were to add it all together?

[vlado]

How many pages is the V-Ray code? I don't know I have to find a tool to count the lines

Best regards,
Vlado

[Dariusz Makowski (Dadal)]

Copy/paste to any web editor? Should give u line count =D but from other hands how long are lines? =D

[super gnu]

just write a chaos "codelinecounter" it could use raytracing and qmc sampling to work out the number of lines of code without having to count them all. would be the fastest on the market for sure