I’m using the Slave Scheduling to prevent my workstations to render during office hours.
However, the workstation stops the slave as scheduled, but when a collegue of mine has to restart the machine, or a bug occurs or whatever, the slave gets picked up again even if NOT in the scheduled hours! This is troublesome as we’re losing precious computing power during office hours when it’s needed for the artists.
Is there anything that can be done about this currently? If not, please, can you add checks for this in Deadline?
Is Deadline configured to launch the slave when the Launcher starts up? That would explain why the slave starts up after the machine is restarted. You can turn this off in the deadline.ini file for the user that the slave is running under. You can find it at c:\Users%USER%\AppData\Local\Thinkbox\Deadline (assuming you’re on Vista or Windows 7).
Currently, the scheduling feature doesn’t monitor the slave state. It just starts it at time X and closes it at time Y. We could look at adding “monitoring” to it as well in a future version.
Well, the problem then is weekends when the slave is supposed to be rendering at 100% but with restarts after 24 hours of operation.
This mix-up is tripping deadline, obviously and I’m not sure if there is anything I can setup in order to have it work as I intend it to (render ONLY during render hours, if not render hours, DO NOT RENDER AT ALL).
This is interesting – I haven’t implemented scheduling yet, but had hoped to.
Why not have the slave check the schedule during startup, and if it’s outside its “allowed” hours, just decline to start, the same way it does when set to “Disabled”?
That’s a really good idea. When we implemented the Slave Scheduling feature, it was more of a “soft” scheduler where it didn’t enforce the schedule, but I could see us adding an option to made it a strict schedule.
That’d actually make sense. If you need to keep the schedule, it’s really unwanted to have the slave suddenly start rendering (either after a restart or for any other reason) during “OFF” hours.
Also, this scheduler should be a pretty high on the priority list.
We don’t run a big multi-Slave renderfarm but possibly this is something that can be built using Deadline’s ability to incorporate other tools (wrapped in Python); we do use this approach on our much smaller group of machines. If you’re running a back-end of Windows machines a commandscript job that invokes PsExec (from the freely available PsTools suite) can start or stop Slaves on remote machines (ie. one Slave needs to be running; its execution of the job can control other machines where Slaves are or aren’t running because PsExec talks to the machine and not the Slave). Running this PsExec script as a Deadline job allows you to use Deadline’s own scheduler so a stop doesn’t interrupt running jobs; running PsExec outside Deadline (using the Windows Task Scheduler) is a “hard” scheduler that would be implemented regardless of what’s happening on the Slave machine. Depending on how fancy you want to get, you might incorporate other features in an “OnJobStarted” Event Plug-in for things like Wake on LAN and powercfg, so that a submitted job will wake up machines, start the Slaves, and set them to stay awake, then an “OnJobFinished” that could restore the original power settings and/or kill the Slave. The commandscript feature opens a lot of functionality for controlling machine behavior; the limits are generally in finding the tools you want to use and how much Python coding you’re willing to do and for this, once you have a working template for using RunProcess with one external tool (this might be something that Thinkboxsoftware would consider bundling in as an example, as they do for the Shotgun Event plug-in) you can essentially clone that syntax for running anything else.
If you need to keep the schedule, it’s really unwanted to have the slave suddenly start rendering (either after a restart or for any other reason) during “OFF” hours.