It only just dawned on me that while I can manually order Pools, groups are “prioritised” purely by alphabetical order.
Any chance we could have the ability to manually set these in the next release?
Thanks!
Simon
Hi Simon,
Not sure what you mean, Groups don’t affect priorities of jobs, they are boolean Yes/No filters.
If a slave is not in the Group, it won’t pick a job assigned to that Group.
Pools can be ordered to define which Pool a machine should prefer.
thinkboxsoftware.com/deadlin … imits.html
If you mean something else, please clarify!
Okay, so here’s an example:
We use Pools to separate which machines will work on which films, let’s say Star Trek and Star Wars (because those obviously AREN’T things we’re currently engaged on).
So each of our machines will be assigned to one or the other as first or second priority with respect to Pool.
Now, we also separate machines into Groups, according to task and capability.
Let’s suppose I have divided my machines into 16GB and 24GB GROUPS, with the 24GB machines ALSO being members of the 16GB group.
A job that needs 24GB will obviously run only on the 24GB group, but sometimes jobs for the 16GB group will be picked up by 24GB machines, simply because 16GB comes before 24GB in the ALPHABETICAL group order.
This can then result in 16GB jobs loading up on all the 24GB machines, leaving some 16GB machines idle and 24GB jobs stuck in the queue.
Sorry if this sounds convoluted - it’s much easier to understand when you see it happening in Deadline Monitor.
I know it would be possible to use some workaround like renaming groups as A or B, or whatever, but being able to manually control the ordering of groups would be a big plus for me.
Simon
I don’t think this is technically correct.
The reason a job that was assigned to group “16GB” is picked up by a machine with 24 GB is because you added the 24 GB machines to the “16GB” group, NOT because of any alphabetical sorting.
The idea is this:
If you want to LIMIT a job to render only on 16 GB machines, you select the “16GB” group and you should have only 16 GB machines in that group, nothing with 24 GB.
If you want a job to render on 24 GB machines because less memory wouldn’t cut it, you give it the “24GB” group and it will never touch a 16 GB machine.
If you don’t care what machine will render it because it needs less than 16 GB anyway, you don’t assign ANY group.
So when a 16 GB machine comes along a job that needs 24 GB, it won’t touch it.
If a 24 GB machine comes along a job that was specifically set to use 16 GB, it won’t touch it.
If any machine with either 16 or 24 GB comes along a job and it has no group, it will take it no matter what.
So once again, what you see is a side effect of you putting machines with 24 GB in the “16GB” group, not a result of the order of the listing, since the groups order does not affect job priorities in any way at the moment.
The groups were designed to PREVENT some machines from picking up jobs because they don’t meet the hardware or software requirements of the job, not to split the farm so that a machine that is in both the “16GB” and “24GB” groups prefers 24GB over 16GB jobs. It sounds like you want that to be the case, so I will let Ryan comment on whether that would be a possible wishlist item. 
It’s unlikely that we’ll add priority sorting to the Groups feature. As Bobo mentioned, Groups are simply used to ensure the job runs on the machines that are capable of running it. Usually, you don’t want a slave to prefer a 24GB job over a 16GB one, because if the farm is saturated with 24GB jobs, the 16GB will never get touched. However, if that IS the functionality you want, then you probably want to set this up with Pools.
Cheers,
- Ryan
This is interesting and seems to reflect a flaw in our setup.
Thanks for the insights - I am still finding my way around Deadline - so I need to think through the implications.
As always, your help is really appreciated!
Simon