Chaos Corona for 3ds Max > [Max] I need help!
Slow DR Parsing etc
dj_buckley:
Why are DR nodes so slow to join in?
Admittedly it's a relatively heavy scene as you can see from how much RAM it's using. But i'm 25 minutes into the render on the main workstation and in the first screenshot, the nodes are still parsing/downloading assets etc.
Everything is reading and writing from the same server, all machines are very similar spec's, all using the same software Corona 10 Hotfix 2 Max 2024.
Also I can't help but come back to that "DR nodes use more RAM than the main workstation issue" from years ago. It still blows my mind. It shoots up to over 180GB+ on the nodes which then causes them to fail rendering. But the main PC renders it fine and happily churns along at 75GB RAM usage.
As you can see in the second screenshot. DAVECO01 has now failed and reverted back to 'Waiting for Render Start' and DAVECO03 has shot up to over 180GB. Also note on the second screenshot, I'm now 35 minutes into the render. It's taken 35 minutes for one of the nodes to fail and the other to still be on precomputing GI Cache while using insane amounts of RAM, all the while the main workstation has been happily chugging through the render without issue.
Edi: Aaaaaand just as I submitted that post, the second node failed.
Frood:
--- Quote from: dj_buckley on 2023-11-10, 01:03:47 ---Why are DR nodes so slow to join in?
--- End quote ---
Counter question: how long does it take on the master to load the scene, press render and to have it actually rendering the first pass?
--- Quote from: dj_buckley on 2023-11-10, 01:03:47 ---Also I can't help but come back to that "DR nodes use more RAM than the main workstation issue" from years ago. It still blows my mind. It shoots up to over 180GB+ on the nodes which then causes them to fail rendering. But the main PC renders it fine and happily churns along at 75GB RAM usage.
--- End quote ---
You are comparing the wrong data. Those 75GB of the render status window is the active working set of the 3ds Max process, while the 180GB of the DR status display is the ram commit size (additionally: for the complete system. This should not make a significant difference here if the nodes are dedicated and nothing else is running). You'd have to compare the 180GB to the second value of the render status window of the master: 235GB. So the master uses more ram according to your screenshots, not the other way round.
Best is to compare using taskmanager and activating all ram relevant columns in the "Details" tab. Do this on master and slave. Still the question is: who/what requests (and does not use) such a large amount of memory. Do you use any fancy plugin here? I'm aware of strange commit sizes using Max generally, but 75GB vs. 180+ (commit size) looks in fact extreme. Does the master uses "only" 75GB for the process from start or is it much larger when loading/starting to render and later goes down to 75GB?
As for the fail: do the nodes actually crash? As always: logs, logs, logs from the slave will help:
- 3ds Max log: "Max.log"
- DrServer log: "DrLog.txt"
- Corona log: "CoronaMax2024_log.txt", "CoronaMax2024_errors.txt"
Good Luck
dj_buckley:
First question, about 5 minutes to load, 0.5 seconds to press render, less than 5 minutes to start rendering
Master does use more when loading but doesn't exceed 100GB.
The point is, regardless of task managers details etc etc. I can render it on all 3 individually, if I open the scene on each and just render. But I can't through DR.
Another issue while I remember. When I first open a scene, fresh 3ds max, open scene and render. It struggles with all of the parsing and loading and I get ram warnings. However if I cancel the render and render again, it all goes through much quicker with no issues.
I will be able to get it to render by optimizing as there's a lot of unnecessary displacement for this shot etc but it's besides the point.
dj_buckley:
I'll have more time today to investigate. And I appreciate that the numbers aren't direct comparisons. But such a gulf between them seems crazy. The nodes are literally dedicated. Nothing else running on them other than default windows processes. They're just sat in a corner of the room solely dedicated to rendering.
Frood:
--- Quote from: dj_buckley on 2023-11-10, 09:27:38 ---First question, less than 2 minutes.
--- End quote ---
Oh amazing. Starting Max alone takes about 30 seconds on my computer :) So it loads, parses and starts rendering in 2 minutes in fact?
Edit: seen your edit :)
--- Quote from: dj_buckley on 2023-11-10, 09:27:38 ---The point is, regardless of task managers details etc etc. I can render it on all 3 individually, if I open the scene on each and just render. But I can't through DR.
--- End quote ---
That's interesting, more later.
--- Quote from: dj_buckley on 2023-11-10, 09:27:38 ---Another issue while I remember. When I first open a scene, fresh 3ds max, open scene and render. It struggles with all of the parsing and loading and I get ram warnings. However if I cancel the render and render again, it all goes through much quicker with no issues.
--- End quote ---
That's even more interesting because with scenes using all available ram, I struggle with this phenomenon since ever. Look at the graph (older one I captured, but still applies). It shows a BB render node crunching a job. At the fist bubble, I logged in and started another Max session and rendered some scene locally (flat part of passes graph). Second render stops at the second bubble. Look at the ram consumption of the first job: It drops from 15+GB to about 6GB and stays at that level to the end. I can observe this until now, also with larger scenes and larger impact. Sometimes it's even enough to log on and do anything on the node.
One possible explanation is: 3ds max holds an entire copy of the scene while the renderer has another. At some point, a kind of purge seems to happen. I never found out how to trigger it by purpose.
--- Quote from: dj_buckley on 2023-11-10, 09:29:49 ---But such a gulf between them seems crazy.
--- End quote ---
I still don't see that until you check the working set (and not the commit size) of the dr node max process, curious what you will find.
Good Luck
Navigation
[0] Message Index
[#] Next page
Go to full version