mixed licenses

Deprecated Deadline 8 Discussion
1

Hello,

we’re thinking about using a mix of licenses : a fair amount of permanent, and UBL for the production peaks.

I run a few tests, and it seems that when a job has the choice between slaves with the 2 kind of licenses, it’s pretty much random.

I there any way to make sure that the permanent licenses are used first ?
imho the best option should be that slaves could switch to UBL mode if there is no permanent license left.

Cheers,
Pierre

2

Hi Pierre,

Thanks for the feedback. There currently isn’t a way to ensure that permanent Deadline licenses are used first, but we were just discussing the topic internally and we might be able to come up with a straightforward solution for Deadline 8.

We were thinking of having a configurable number (call it X), and UBL slaves would only pick up jobs when at least X permanent (PERM) slaves are rendering.

For example, if you had 10 PERM slaves and 5 UBL slaves, you might want to set X to 8. Once 8/10 PERM slaves are rendering, then the UBL slaves can join in. The reason you might not want to set X to 10 is in case one of your PERM slaves goes offline.

We might also want to look at a more dynamic system in the future where slaves switch their licensing type between tasks depending on how many PERM slaves are rendering. That’s something we definitely won’t be able to squeeze into Deadline 8 though.

Do you think the configurable X setting would work for you for now?

Cheers
Ryan

3

Sounds good to me.

One question, though, how would this interact with pools ?

Thanks,
Pierre

4

Pools would not have any impact on the system. When a UBL slave is making the decision to pick up jobs or not, it’s solely based on the number of PERM slaves that are already rendering, regardless of which pools those slaves are in.

Would you want pools to impact the system? If so, in what way? We will likely try to keep this system simple initially, but we definitely want to consider how we can expand upon it in the future.

Cheers,
Ryan

5

Hello,

Thinking out loud, sorry :slight_smile:

Let’s say we have 20 slaves, 6 with UBL and 14 with traditional licenses.
There is 2 pool of 10 slaves, 3 UBL and 7 traditional each.

If the “X” number is set at 12, if a job ask for 10 concurrent slaves on pool A, it won’t get the 3 UBL ones before another job activates 5 slave on the other pool, which is kind of not very good.

We would have to design our pools/groups taking care of the UBL factor, then. But I’m not sure it’s going to be that easy with a large number of pools and groups.

Cheers,
Pierre

6

Hey Pierre,

Thanks for the example. Things like Groups and Limits would also be problematic as well.

The dynamic system I mentioned would be the proper solution here. In your example, that job would get 10 PERM slaves on pool A, and if another job was submitted to pool B, it would simply get 4 PERM and 6 UBL.

Doing some thinking out loud myself now… :slight_smile:

One way we could implement a dynamic system would be to simply have the slaves always try to check out a permanent license. If that fails (ie: because all licenses are currently checked out), it would fall back to UBL.

One concern with this is what if the license server has simply gone down? Under this system, all 20 slaves would start trying to pull UBL. That may be fine in some cases, since it allows the rendering to continue, but it could also mean unexpected UBL usage.

So maybe what we ultimately need for a system like this is a configurable cap on the number of UBL slaves. In your example, you would set it to 6.

How does that sound?

Cheers,
Ryan

7

Hey Pierre,

I discussed this with one of our lead developers yesterday, and we’ve determined that while we definitely want to introduce a more dynamic system, it will be best to wait until at least Deadline 8.1.

Back to your example though, it should still be possible to make use of those UBL slaves.

  • Again, let’s assume you have 20 nodes and 2 pools (poolA and poolB).
  • You can assign these pools to the first 10 nodes: poolA, poolB.
  • You can assign these pools to the remaining 10 nodes: poolB, poolA.

Note that the pool order is reversed for the remaining 10 nodes. With this configuration, half of your nodes will prefer jobs in poolA, but will fall back to jobs in poolB once all the poolA jobs complete. The reverse is true for the other half of your nodes. Setting up pools like this allows you to make optimal use of your render farm, but it also allows the original system I proposed to work without starving the UBL nodes.

Cheers,
Ryan

8

Hello,

I’ve tested the 8.0.0.62 new “Require Minimum Number of Fully-Licensed Rendering Machines” option, it seems to work as expected, thank you !

Cheers,
Pierre

9

Awesome! Thanks for the feedback.

Cheers,
Ryan