I’m mid render of 30 shots and have added more with increased priority values per shot. RC1 seems to be ignoring the priority value and renders the shots as per the submission order.
I haven’t checked this in the latest RC because of this run of renders, but as soon as they are finished I’ll upgrade my systems.
Process:-
Submit job A @ default 50 priority.
Submit next job B @ 52 priority.
Submit next job C @ 56 priority.
Submit next job D @ 58 priority.
Submit next job E @ 60 priority.
Submit next job F @ 62 priority. etc
New jobs to run inbetween already submitted jobs
Submit next job G @ 61 priority.
Submit next job H @ 59 priority.
Submit next job I @ 57 priority.
Submit next job J @ 55 priority.
Render order should now be A(which is already running), F, G, E, H, D, I, C, J, B
I would now expect these jobs to render in the priority order, not the submission order, which is what is happening.
Tim.
Update, I have selected all jobs and checked the ‘Job is interruptible’ flag and now the priority order is being taken into account. Surely I shouldn’t need to check this for the priority to be accounted for.
Can I set the ‘Job is interruptible’ flag to be on by default?
Tim.
Update 2.
Ok so the priority was ignored by jobs already in the queue, but was taken into account when the new jobs had reached the top of the queue according to submission time. Something here is broken.
I still have seven shots to run before I can test this in RC3, or the latest version.
Tim.
I tried to reproduce this here by running this test. Note that in this test, all jobs had 3 tasks, all used the same pool and group, no jobs had a machine limit or whitelist/blacklist, and no jobs used any Limits (aka: Limit Groups).
- Submitted p50, let it pick up
- Submitted p52, p56, p58, p60, and p62
- Let p50 finish it’s current task, at which point it picked up p62 as expected
- While p62 rendering, submitted p61, p59, p57, and p55
- Let p62 finish all 3 tasks, at which point it picked up p61 as expected
- The rest of the jobs went in this order: p61, p60, p59, p58, p57, p56, p55, p52, p50 (note that p50 only had 2 of its 3 tasks left here, since the first task finished in step [1] above).
So everything appears to be functioning properly. Can you provide more information about your jobs? For example:
- Do your jobs consist of multiple tasks, or do they just have one task each?
- Are you currently using pools or groups? If so, do these differ at all between the jobs?
- Do you have a machine limit, or a whitelist/blacklist set for any jobs?
- Do any of the jobs use any Limits (aka: Limit Groups)?
Cheers,
Hi Russell,
Thank you for checking this for me.
I have two pools and two groups both named as full for all render nodes and merge for the merging machine. All jobs are Maxwell, running co-operatively. I don’t assign a pool or group to the co-op renders so this stays as default ‘None’, I just assign merge pool and group for the merging part of the job.
4 concurrent tasks per machine, no other limits
40 jobs in co-op submission
Local rendering on
SL override on
No split co-op jobs so I have two jobs in the queue per render.
No machine limit, whitelist or blacklist
The first batch had a Job name 1804 and the second had a job name 1805. I’ve attached the monitor screen grab with the job start order organised with the first job at the bottom, priorities are on the right.
Cheers,
Tim
Thanks for the details and the screen shot. I tried to set up a similar situation here, and I still can’t reproduce what you’re seeing. Can you open your Repository Options from the Tools menu in the Monitor while in Super User Mode, select the Job Settings page, and let us know what the Job Scheduling Order is set to?
Note that I am testing with RC3, so hopefully you can upgrade soon and let us know if this problem still persists.
Cheers,
Ok I think you’ve nailed it mate. The job scheduling is set to submission, priority, pool. I see that I need to change this to priority, pool, submission date for my set up.
I’ve switched it now and will report if I have the same issue.
Cheers sir,
Tim.
