|
|
View Forum Thread
Anyone can view the forums, but you need to log in in order to post messages.
> Forum Home >
Feature Requests >
out of order execution of Generic (support) scripts
|
Fri, 10/Dec/2010 1:04 PM |
Martin
69 Posts
|
I would love to have a possibility to submit support scripts for general maintenance (like copying configuration scripts, plugins, shaders etc.) without need to wait in the general que of renders and wihtout need of making all the nodes online, when I do not need them to render immediately after my script finishes.
It could be some special kind of a job able to run immediately and simultaneously with normal jobs.
Hope it is not completely out of bounds of Smedge philosophy . . :)
|
|
|
|
Fri, 10/Dec/2010 1:50 PM |
QuakeMarine1
177 Posts
|
i am not sure what the current Generic script is missing to fit your need ?
each engine run the genereric once - put it to highest prior and boot your engins
keep job in GUI as long as the last engine join somewhen
|
|
|
|
Sat, 11/Dec/2010 5:01 PM |
Martin
69 Posts
|
It is missing exactly what I wrote. Out of order execution.
If you have several jobs in queue and each batch takes like 2 or 8 hours of render submitting support script with higher priority just to copy some configuration file is useless.
Or should I kill the nearly finished renders our client is waiting for just because I want to copy something?
Also making offline machines online just for taking and executing the support script and subsequent killing all renders it starts to render by making them offline immediately is not my support dream.
I'm still in the conviction that it is not a bad idea and it could rapidly improve usability of Smedge . . .
|
|
|
|
Mon, 13/Dec/2010 1:28 PM |
Robin
1138 Posts
|
I understand what you want, and already have plans to implement something like this. The idea is that you can have different Queues, and different types of jobs are queued up in one of these separate queues. Jobs queued in one Queue would not affect Jobs in another queue.
There is already a bit of this implemented. The "Large File Transfer" Product is actually queued separately from all other types of jobs. This allows transfer jobs to be queued and dispatched while other work may be going on a machine, and avoids other work from having to wait while a large file transfer finishes.
The database redesign that is currently in development for Smedge 2012 will be a big part of making this work well, so I expect it will be something to look for in that release.
Thanks
-robin
|
|
|
|
|
|
. |