we have a question regarding the partitioning of Particle Flow setups with Krakatoa through Deadline regarding the feature to use more than one instance per machine.
We were following the workflow in the Krakatoa documentation under “Partitioning Using Deadline”. We set it up as “One Job Only, Partitions As Tasks” and configured it to use 2 concurrent tasks. Unfortunately, both instances of 3ds max were running on the first of the 8 cores/threads and all the others were idling. Shouldn’t the tasks be spread across several cores (in this case 2)? Or are we misunderstanding something?
Normally, the OS should deal with applications running in parallel and give them as much CPU time as they need. In our case, we launch multiple instances of 3ds Max from the same instance of Deadline Slave.
Note that this is different from running multiple Deadline Slaves (in Deadline 7, only one license of Deadline would be used in both the Concurrent Tasks and Multiple Slaves cases), but Multiple Slaves allows multiple JOBS to be run in parallel (e.g. a simulation and a 2D compositing tasks at the same time). And while the Concurrent Tasks is a Job Setting that the submitter can set, multiple Slaves require the user to define and launch them explicitly.
Since PFlow is totally single-threaded, it is very possible that not much of the other cores would be loaded. You could try launching 4 or 8 concurrent task and watch the Task Manager to see if more than one core would be loaded. When I have tested this in the past, Windows would deal with providing the CPU time to all the tasks as needed. There is nothing in the submission that tells the Tasks how to use the CPUs.
We just tested the “One CPU per Task” setting from SMTD with Krakatoa/Deadline partitioning as was suggested in that older thread and it works exactly as expected.
Now, we actually would love to see the improvement in the Krakatoa rollout that you ‘promised’ back then:
That would be awesome!
Could this actually also be implemented in a way that leaves the same “One CPU per Task” setting in the SMTD untouched? This way the artist would not really have to think about checking this setting every time (and most artists like to forget such things ). We’re rendering a lot of V-Ray so in most cases it doesn’t make sense at all to use “One CPU per Task” as default.
This seems to be one of the cases where my previous Me knows more than my current Me
Also known as getting old
The One CPU Per Task did not exist at all when Krakatoa was written, so my reply from today still stands - I would expect Windows to handle that automatically. The Open CPU Per Task actually changes the affinity, so it would be more explicit. It sounds like it is doing a better jobs…
If you want to make the change yourself, you can open the file KrakatoaGUI.ms, locate the function SubmitOnePartitionJobToDeadline() and make the following changes to the relevant places (see the --NEW: lines):
[code] fn SubmitOnePartitionJobToDeadline partitionStart partitionEnd quiet:false partitionMode:#tasks PartitionRange:true =
(
if( (not quiet) AND (not SubmissionSanityCheck()) ) do
return false
-- Save some values that we change temporarily
local savedRenderTarget = FranticParticles.GetProperty "RenderTarget"
local savedParticleFiles = FranticParticles.GetProperty "ParticleFiles"
local savedJobName = SMTDSettings.jobName
local savedOOM = SMTDSettings.OutOfOrderMethod
local savedPreviewJob = SMTDSettings.RenderFramesPreviewJob
local savedOneCPUPerTask = SMTDSettings.OneCpuPerTask --NEW: Store the old value of the OneCPUPerTask property
/*ENFORCE SETTINGS! - This is to avoid conflicts with SMTD GUI that might have been opened AFTER Krakatoa and could overwrite these values! */
try(SMTDSettings.SequentialJob = true)catch() --available sequential rendering in Deadline 2.6 and up only!
SMTDSettings.LimitEnabled = true --always enabled limit
SMTDSettings.MachineLimit = getInI "JobSettings" "MachineLimit" SMTDSettings.MachineLimit --set the limit from the INI
if SMTDSettings.MachineLimit == 0 do SMTDSettings.MachineLimit = 1
SMTDSettings.RenderFramesPreviewJob = false
SMTDSettings.OutOfOrderMethod = #normal
SMTDSettings.OneCpuPerTask = true --NEW: Override the OpenCPUPerTask value
-- Close the render scene dialog so we can change render properties
renderSceneDialog.close()
rendSaveFile = false
…
-- Restore all the partition values to their original
FranticParticles.SetProperty "RenderTarget" savedRenderTarget
FranticParticles.SetProperty "ParticleFiles" savedParticleFiles
SMTDSettings.jobName = savedJobName
SMTDSettings.OutOfOrderMethod = savedOOM
SMTDSettings.RenderFramesPreviewJob = savedPreviewJob
SMTDSettings.OneCpuPerTask = savedOneCPUPerTask --NEW: Restore the old value of the OneCPUPerTask property
thanks for the code. But i think we’ll stick to opening SMTD first and set it up there. Changing this inside KrakatoaGUI.ms would be required on all machines were people are using it. So for the time being it’s easier for me to tell them where to activate the feature. Doing this ourselves would also require us to change the .ms file with every Krakatoa update. And i’m still hoping you can/will implement this in the next update
