|
|
View Forum Thread
Anyone can view the forums, but you need to log in in order to post messages.
> Forum Home >
Feature Requests >
Auto-distribution of cpus to evenly set limited cpus to each user.
|
Thu, 25/Nov/2010 9:01 AM |
Jamie
102 Posts
|
This is a bit of a weird one I know, but please indulge me on this brain fart. :D
Ok. Artist submits job onto clear farm they get all cpus, that's ok. They add a raft of jobs on this empty farm, that's ok too.
Another user or two start submitting jobs, the priorities are all similar in their renders but then a priority escalating frenzy ensues and before you know it the queue is being hogged by users who just want their stuff as fast as possible which isn't always (mostly un-intentionally btw) in the other artists favour.
This is where I'd usually come in and rectify and start limiting cpus on their jobs, talking with production more about who's really more important today renderwise, which is fine that works well enough, but is there a way to limit the cpus across the users jobs automatically.
eg: user 1 would have 200cpus 'evenly limited across all their jobs according to their priority' as would users 2 and 3 have 200cpus each.
As each user is done on the farm the "average cpus allowed per user" (the name I was thinking on this option/feature) would dynamically change as each artist came on and off the farm.
I was thinking of scripting it up here on the open source frame works we're using with Smedge but I thought it'd be a damn good feature for Smedge itself to actually ship with... god knows there'd be a render wrangler who wasn't as harrassed as much resolving this one if you made this a feature.
Now, I may revise this post but I thought I'd fire it up here before I forget.
So to surmise, would it be viable to have an auto allocation of cpus based on number of users on the farm (as well as priorities?!)
Let me know what you think.
cheers
Jamie
|
|
|
|
Fri, 26/Nov/2010 4:17 PM |
Robin
1138 Posts
|
One thing you should try is to switch to "round robin" dispatching. This makes sure that every job of the same priority gets some work time. This is in the configure master dialog box, on the distribution tab.
There is also a pending feature request to have the job priority determine the minimum percentage of the available engines This is a bit more involved, but I do have a plan to get it to work.
|
|
|
|
Thu, 05/May/2011 12:35 PM |
Jamie
102 Posts
|
I'm finding that works well enough when artists submit similar number of jobs with similar priorities but one artist can easily submit 10 or more jobs at escalating priorties in their preferred order of completion which can be similar to the other user's 2 jobs at same priorties
Thing is that there's the occasional free for all in terms of priorities, no matter how often you explain the general rules of how to prioritise their submissions, and that's when users come annoyed since they're work hasn't started. Specially when there's no deadlines in early production & animation.
Is there any scope for adding 'enable even user cpu allocation' to the round-robin routines to help adjust or dynamically adjust cpu limits and such.
I'm working up a pulse system to do this sort of thing (poll jobs active, list users, count active machines, average out job cpu limits etc) but it's part of a long haul project which, if this approach works in principle, I thought would be cool to appear in smedge as an option.
I can tell you how well it works once in practice if you want, sort of test it out.
Thoughts on this are welcome.
Cheers
J
Edited by author on Fri, 06/May/2011 5:46 AM |
|
|
|
Mon, 09/May/2011 2:04 PM |
Robin
1138 Posts
|
One existing tool that may help in some situations for you currently is that you can put a limit on the number of workers from any given job. This may be useful for keeping a high priority job from completely monopolizing the farm, but it is also a hard limit on the maximum, so if nothing else is queued, the rest of the farm will be idle if a job has hit its maximum.
|
|
|
|
Wed, 18/May/2011 12:11 PM |
Jamie
102 Posts
|
Indeed, that's also part of what I'm setting up the Pulse system here to do. If it sees a decrease in users and the limits are too low then it'd update them to use the rest of the cpus.
It's actually through the dynamic watching for user jobs and setting of that hard limit (on the fly) that I plan to retract the more dominant user submits from hogging the farm.
J
|
|
|
|
|
|
. |