Over a year later, we still don’t use the groups feature. And pools are basically just the identifier of the submission plugin ie (3dsmax, fusion, combustion). Then we filter special cases with the limit groups. 64bit, more than 8GB, brazilLicense etc.
How are other people using these features, pools and groups? Because they seem to be more of a nuisance than a feature. I’d rather a slave know what it has installed and set it’s own pool, limit group etc.
I’d like people to feel more comfotable with submission and job editing features. And I’d like to know for myself how I should be setting up our slaves in pools.
Hi Ben,
We have a reasonable size farm and our setup is always getting more complicated especially towards the end of a project or more recently, multiple projects with the same deadline and new technology / software being added during production for future projects! We use pools like most other studios, but we also use groups to categorise the specs of our machines as we have quite a few different generations of workstations/render nodes as our pipeline has evolved over the years. In addition we use limit groups solely for limiting floating licence schemas across the network. I always make a conscious effort to keep these standards consistent as it really helps the artists understand how deadline is working under the hood to prioritise jobs in the queue and their order of execution.
Presently, the way SMTD UI is configured, “pools” & “groups” are highly visible to the user and you can quickly write some Sanity checks to cross-reference any local studio settings against submission settings. This means, that users can quickly understand what pools and groups mean with regard execution. Slightly more hidden away are “limit groups” which is where I have sanity checks point the user to if they need a certain “licence limit group” applying to their job submission.
Combined with another 66 custom sanity checks before submission, our rendering pipeline is rock solid these days, thanks to Deadline’s highly customisable architecture
The great thing is that if you’re a smaller shop, you can just ignore these additional features, but if you ever need them…
I feel the Groups feature is more like a simpler to use “White List Slaves” option and not so much like Limit Groups.
Limit Groups are a way to prevent more than a given number of machines from pulling a license from a limited pool of licenses. For example, if you have 100 machines but only, say, 10 Krakatoa network licenses, you don’t want more than 10 machines to pull a license at a time, REGARDLESS of what Pool or Job these machines are working on.
We use Groups to create lists of similar hardware / software installations to ensure that a Job submitted for a project gets rendered with the right slaves, while using the Pools to distinguish between Projects to share the farm between groups of artists working on completely different shows. For example, let’s say we have 100 machines and some users working on VFX Project A and VFX Project B. We create two Pools, one called “Show A” and one called “Show B” and assign machines that are dedicated to 3D rendering (as opposed to fluid sim, RnD etc.) to both shows. We can have 50 machines listing Show A as 1) in the Pool list and 50 machines listing Show B as 1) on the Pool list. This means that if Show A is not rendering much, Show B will pull all 100 machines, but if Show A submits jobs, 50 of the machines will move to Show A as soon as they finish whatever they were doing before because A is higher on the Pools priority list. Now let’s say Show A renders in Krakatoa and thus needs lots of RAM but can live with fewer CPUs, while Show B can live with 4GB of RAM but would prefer 8 cores for VRay/Brazil rendering. We can now put all 100 machines into multiple Groups (one machine can be in many groups) that describe the hardware characteristics and eventually the software that is installed (3dsmax, fusion etc.). So when an artist working on Show A is submitting a job that needs lots of RAM, he can select a group that is called “3dsmax64 16GB RAM” and he can be sure that no machine that is not on that Group will ever pick the job, regardless of pool settings. If no Group is specified (empty string entry), any machine will be allowed to work on the job. One could theoretically go to the Limits controls and move all slaves that are known to have 16GB of RAM to the Whitelist and possibly even save that Whitelist as a preset for future use (both SMTD and Monitor allow this), but this is very explicit and much more convoluted to set up. Plus you can use Blacklisting / Whitelisting ON TOP of the Group to ensure some bad boys don’t work on your job. But maintaining Groups with similar hardware/OS/software is so much easier and anyone could pick the right group based on his knowledge of scene complexity and hardware requirements…
This is in short how it was intended to be used, but you are free to leave the Group empty and just use the Pools.
