AWS Thinkbox Discussion Forums

Missing or fixing and features request

Missing or fixing :
-Tool tip in the submit maya job window doesn’t work anymore: It existed in deadline 5
-The submit maya job window doesn’t retain the previous settings: We have to reenter all the settings again from scratch each time we need to submit a new job
-In the submit maya job window the machine list button doesn’t work
-When the network goes off and on(network issue), deadline slave stop working and because it doesn’t automatically reinitialized or doesn’t resume(because it shutdown), we sometimes lose a night render.

Feature request:
The priority order is missing an in-between order meaning if we have several scene with the same priority we never know which one will render first, even when we sort by priority it never gives the exact order in which it will render(which in this case need to be fixed i think), plus it would be useful to add an arrow that will let us order the in-between job of the same priority in the order we want it to be rendered.
I know we can change the priority of each job but its not practical when you have 10 jobs with the same priority(including several other jobs already sent) and you have to order them individually, because something came up and you had to change there in-between order.

Thanks!

On the todo list.

This will be fixed in beta 7.

Logged as a bug. The Limits and Dependency buttons also aren’t hooked up.

Can you send us the slave log from when this happened? You can find the log folder from any of the Deadline applications by selecting Help -> Explore Log Folder. The slave is supposed to stay running, and we thought we had this covered, but it looks like there is a still a case where it can go down.

The tie breaker for jobs with the same priority is the submission date. Older jobs will always be preferred over newer jobs if all other things are equal. So to get a rough sorting order, you can first sort on the Submit Data/Time column so oldest jobs are at the top, and then sort on Priority so that the highest number is at the top.

Note that that other things can affect the order in which jobs are rendered, like Pools, Machine Limits, Limits, etc. There is also no “global” job order, since slaves that are assigned to different pools or groups have their own order in which they would process jobs.

In your case, you might want to create a pool that is assigned top priority to all slaves. Back when we were in production, we had a pool called crisis_friday. If a job absolutely had to go through now, we would just change its pool to crisis_friday so that the slaves would prefer it over all other jobs (since scheduling order is based on pool, priority, and then date time).

Cheers,

  • Ryan

About the network issue, in fact it seems to go fine, the slave didn’t stop working even after the connection went out.

Ah, that’s good. :slight_smile:

I think the ordering of the jobs in the list is still a little bit confusing and messy, meaning that there should be a better way to view the order in which the jobs are going to render without having each time to click on the bars to sort them.
I think it would be good to find “a way” to let the jobs order themselves automatically taking in consideration everything:priority, submission date and pool priority so we know which one is going to render first and not have to order them manually each time.
Cause what happens is that when you have many jobs sent and you ordered them, lets say submission first then priority then pool you get the correct order in which it will render, but then when you add a new job it doesn’t place correctly you have to reorder those same tabs again and thats annoying.
Plus its still not practical to go into each jobs and change there priority from inside(once submitted), it would be nice to have a button thats lets us control that setting from the outside, maybe the pool too(cause it has its impact on the priority too).
(By the way we’re still on Beta6)

The problem is, there is no “global” job queue order. Each slave can have its own order based on how pools and groups are assigned. For example, a slave with pools “poolA, poolB, poolC” will have a different priority order than a slave with “poolB, poolC, poolA”. When we were in production, we had over 200 slaves and over 10 pools at any given time. There were different combinations of pools across those slaves. Accurately predicting the order of jobs becomes quite difficult in this situation. Then you still have to factor in things like machine limits, limits, render time estimates for the current active jobs, etc.

A little while ago, we had thrown around the idea of a Monte Carlo system that could predict when a job would finish, and in theory the same system could be used to simulate the order in which jobs will render. This would be a significant undertaking though, so it’s not in the short term road map. Maybe one day…

It sounds like you want the ability to shift the priority of a large set of jobs as your priorities change. You can already do this on the pool level from the Manage Pools dialog, which you can access from the Tools menu in super user mode. When we were in production, we had pools for each show we were working on. If one show was approaching its deadline, we could use the Manage Pools dialog to shift the priority of that pool up a few notches across the selected slaves. When things settled down, we could decrement it back to the previous level.

Cheers,

  • Ryan

OK thank you, I understand the complexity of the situation.
Would tabs like the browser chrome help with the situation separating for example pools or group, wouldn’t that make it a little bit more organized?.

You mean like different lists that show different orders for different pool combinations? Yeah, maybe something like that could work. There could even be a right-click option for a slave to pop up a list showing it’s current queue order. We can put something like this on the wishlist, but it would more than likely have to be a post-6.0 feature.

The retain settings in the submit maya job has been fixed, but “the submit maya file” wasn’t.
We want it unchecked each time we submit a new job.
Even after we unchecked the submit, when we close and reopen the “submit maya job” window it gets checked again.

Thanks! This will be fixed in beta 8. It turns out there was a bug that prevented the sticky settings for any check box control from being restored.

Privacy | Site terms | Cookie preferences