At this time you can limit the machines of a running job and release this limit after a certain % is done.
current situation:
I have 5 jobs running and 10 machines in total. So I’ve assigned each job 2 machines to get all things moving at once.
however, some jobs are quicker so at some point there will be some idle slaves that are available.
At this moment i make a guess on which job I think goes quickest, adjust the machine limits and the job priority so that all start with 2 slaves per job and when one job is done they are added to a job with lower priority.
perfect situation:
The machine limit options would have an additional option to include any ‘idle for x minutes’ machines
This way the machine limit assignment would still work with jobs with equal priority but when slaves have been freed up and not been given a new task of their previous job they will be added to other running jobs.
alternative:
Would it be simpler/make more sense to have a “balance farm power” option where you’d be able to list machines that will automatically balance all their available power over jobs with a certain minimum priority threshold?
To me this actually seems to be something that would be a great feature or have I overlooked some existing similar functionality?
Here are the docs explaining the available options. This is currently in the PDF/CHM documentation for 6.1:
The following options are available:
First-in First-Out: Job order will be based solely on submission date, and will be rendered in the order they are submitted.
Pool, First-in First-Out: Job order will be based on the job’s pool first, with submission date being the tie-breaker.
Pool, Priority, First-in First-Out: This is the default scheduling order that is used. Job order will be based on the job’s pool, then priority, with submission date being the tie-breaker.
Priority, First-in First-Out: Job order will be based on the job’s priority first, with submission date being the tie-breaker.
Priority, Pool, First-in First-Out: Job order will be based on the job’s priority, then pool, with submission date being the tie-breaker.
Balanced: Job order will be balanced so that each job has the same number of slaves rendering them at a time.
Pool, Balanced: Job order will be based on the job’s pool first, with a balance being applied to jobs that are in the same pool.
Pool, Priority, Balanced: Job order will be based on the job’s pool, then priority, with a balance being applied to jobs that have the same pool and priority.
Priority, Balanced: Job order will be based on the job’s priority first, with a balance being applied to jobs that have the same priority.
Priority, Pool, Balanced: Job order will be based on the job’s priority, then pool, with a balance being applied to jobs that have the same pool and priority.
Weighted, First-in First-out: A weighted system that takes priority, submission time, number of rendering tasks, and number of job errors into account, but does not take pools into account. If two or more jobs have the same calculated weight, the submission date will act as the tie-breaker.
Pool, Weighted, First-in First-out: A weighted system that still respects pool priority. If two or more jobs have the same calculated weight, the submission date will act as the tie-breaker.
Weighted, Balanced: A weighted system that takes priority, submission time, number of rendering tasks, and number of job errors into account, but does not take pools into account. A balance will be applied to jobs that have the same calculated weight.
Pool, Weighted, Balanced: A weighted system that still respects pool priority. A balance will be applied to jobs that have the same calculated weight.
Weighted Scheduling
For the weighted options, you can control how much weight is applied to the job priority, submission time, number of rendering tasks, and number of errors. Deadline then sorts by this weight so that jobs with the largest weight value have the higher priority. Note that the weight values can be negative. For example, if you set a negative weight value to the number of job errors, a job with more errors will end up having a lower overall weight so that precedence is given to other jobs in the queue.
Here is how the weight is calculated:
weight = (job.Priority * PW) + (job.Errors * EW) + ((NOW - job.SubmissionTimeSeconds) * SW) + (job.RenderingTasks * RW)
Where:
PW = priority weight
EW = error weight
SW = submission time weight
RW = rendering task weight
NOW = the current repository time
Note that because the job submission time is measured in seconds, it will have the greatest impact on the overall weight. Reducing the SW value can help reduce the submission time’s impact on the weight value.
