Hey,
I was intrigued by the announcement of more flexible power management in Deadline 7, but I can’t seem to find any information about this? Also the UI looks the same.
I basically looking to get better management for workstations, and to utilize their computing power without manual power on/off or disruption to the users experience with the workstation.
Hi Toke,
The release notes in v7.0 mention it here:
viewtopic.php?f=204&t=12098
Check out the sections titled:
“Slave Scheduling Improvements and Idle Detection” & “Local Slave Controls”
“Local Slave Controls…” can be found in launcher & monitor > tools menu (towards the bottom)
&
“Configure Slave Scheduling…” can be found in monitor > tools menu (just below “Configure Repo Options…”).
So, in terms of machine idle detection (lack of keyboard/mouse/wacom activity), you have both local slave controls configured by either artist or overridden by sysadmin AND with slave scheduling, you can also utilise these idle detection settings again as well, combined with a slave schedule for timed start up or shutdown. All working across 3 x OS platforms.
In terms of PM, we are not touching the actual machine power startup/shutdown beyond the already shipping features in the PM section. These new features are all about increased flexibility and allowing studios to maximise their workstation compute power which is typically under-utilised.
Feedback is most welcome in the beta forum 
Thanks Mike. Got it all working, will see how it fares the next month or so.
I’m finding that when Pulse sends out a Machine Wake up call, it starts the slave on all machines that are already on.
Having the “Number of Slaves To Wake Up Per Interval” to 0, seems to not wake up any machines so I have it at a number. Would this be the reason why the slaves turn on?
Yep. Setting it to 0 should effectively disable the feature. If a machine is already on, then the slave should be starting as a result of the machine wake-up call.
You should be able to create multiple “machine groups” to give you configuration/flexibility of what happens to what machines and when.
(This setting “Number of Slaves To Wake Up Per Interval” should really read: “The Max. Number of Slaves To Wake Up Per Interval”
Yep. Setting it to 0 should effectively disable the feature. If a machine is already on, then the slave should be starting as a result of the machine wake-up call.
That worked great:)
I was wondering whether you could force the slave to not stop when not idle anymore?
Say you have an artist that wants their slave on, and can accept the performance hit. If the repository is configured to stop the slave when not idle, the local slave configuration can’t do anything about it. Basically a force slave on mode.
Hi,
See attached screen-grab. You can control the IDLE settings on a local slave via the locally running launcher or as a user with high enough permissions (control access via the “Manage User Groups…” system), you can right-click a slaves properties and modify it for multiple machines. Note, it’s not repository wide, but slave centric settings. Essentially, you could un-check the last checkbox: “Stop Slave When Machine Is No Longer Idle”. You could lock users out of the local setting via permissions and control at IT level via monitor. ie: Don’t use any slave scheduling for workstations but rely on the IDLE detection configuration, during ‘office hours’. You can also use the slaves properties to control how much CPU affinity it has.
[attachment=0]Screen Shot 2014-09-24 at 10.07.55.png[/attachment]
Essentially, you could un-check the last checkbox: “Stop Slave When Machine Is No Longer Idle”.
When I have configured the global settings (see “global”), neither of the slave properties (see “slaveProperties”) or the local slave properties (see “localProperties”), have the “Stop Slave When Machine Is No Longer Idle” checkbox checked so I can’t un-check them.
Ah, I think I understand the confusion now. The Idle detection settings in the Slave Scheduling are independent of the slave/local Idle detection settings, although they both require launcher to be running.
So, you would un-check the slave scheduled checkbox, but enable it at the slave/local level. You could create a special Slave Scheduling Group for the users that want to control this and others can stay in the original slave scheduling group.
We need to write the slave scheduling docs - which I believe is on the ToDo list in the next couple of weeks!
So to make this work I have to;
In order for the artist to take control over the local slave, they have to modify the slave scheduling?
I would have a checkbox on the local slave settings called “Inherit from Slave Scheduling”. If this checkbox is enabled you would have greyed out all the idle detection settings, potentially with a preview of what the slave scheduling settings are. If you un-check “Inherit from Slave Scheduling”, the idle detection settings becomes enabled and the slave is controlled from that.
Hmm…please let me confer with a colleague later today and someone will come back to you on this topic.
Hi Toke,
So, discussing this further internally, to clarify; anything in the global Slave Scheduling settings takes precedence over the Local Slave Controls for the same machine. I think you want to allow the user of the machine to override the global repo settings, but I could see arguments against that from other users. Perhaps, we need to make our user security permissions more granular for “Modify Slave Properties”, so it can be handled one way or the other?
Yeah, I can see how that could help in your proposed configuration.
Yes, that should work in it’s current state.
They shouldn’t need to, as this machine would no longer be a member of a slave scheduling group. I wonder if anyone else in the beta forum has a view on this and the new “slave scheduling” & “local slave controls” features?
Just to clarify, I propose this to be reversed, so Local settings takes precedence over global settings. This would make it easier to switch between local and global control.
Note that while unlikely, it is possible for a slave to be in more than one scheduling group, which makes inheriting from the Slave Scheduling a bit… awkward. Instead, what if we added a checkbox called “Override Slave Scheduling Settings”? If unchecked, all the idle detection settings would be greyed out. In your case, your artists would check that box, and then set their own settings. I think this still gives you the behavior you’re looking for.
Let us know what you think!
yup, that is pretty much what I was looking
I was wondering whether this feature could take the machine’s on/off state into account? Basically so it won’t start up any slaves on already turned on machines.
If you have a machine in a group that you want to wake up when there are jobs available, wouldn’t you also want that machine to participate if it’s already on? In addition, we send the “start slave” command as a backup in case the slave didn’t start when the machine woke up from being offline, so we probably wouldn’t want to change this behavior for this specific reason.
Cheers,
Ryan
In the case of workstations, they are already on when the wake-up call is send out, and they keep getting slave turned on. I would still like to have the workstations wake up, as when a workstation is free (no one working on it).
Would it not be possible to have this command optional? With the idle scheduling, and the machine start up with slave, this command is redundant and is just spamming the already turned-on workstations with artists on them.
As I mentioned in my previous post, it’s used as a backup. For example, if the Launcher isn’t configured to start the slave when the launcher starts, simply waking up the machine won’t be enough to ensure the slave is running. By sending the “start slave” command, it ensures the slave is running. Making it optional will result in the slave not starting reliably for the users that disable the option, and I don’t think that’s something we want to do.
Do artists typically turn off their machines? It might just best to simply remove the workstations from the machine wakeup group, and just rely on slave scheduling and/or idle detection to ensure the slaves are running on workstations when appropriate. As long as your artists don’t turn off their machines when they leave, this should work.
Cheers,
Ryan
And this option couldn’t be on by default? So people who just need to default configuration don’t have to do anything, but there is the option to turn it off.
I would like Deadline to manage the machines, and not have to manually turn machines on and off, which is how it is working now but with the slave keep popping up. I know its a small thing to ask for:)
