It would be very handy to have a view added to the Monitor that allowed interactive re-prioritization of farm jobs. Basically, it would be a drag-and-drop list view of jobs, with fixed sorting by priority (top-to-bottom). Dragging and dropping a job in the list would adjust the priority of the dragged job so it fit in between the two jobs it had been dropped between. This could either be done in “realtime” as jobs were dropped, or changes could all be queued (with a visual cue in the list), and then applied using a separate “Apply” button or something similar.
If necessary, it could also potentially bump the priorities of neighboring jobs to make space for the newly-dropped job (in lieu of a mutable tie-breaking job attribute).
This feature would probably be more successful with the inclusion of an expanded range of possible priorities (see request here: viewtopic.php?f=156&t=9570).
Would you expect a system like this to take pool priorities into account, as well as other things like groups, machine limits, whitelist/blacklists, Limits, etc? The reason I ask is that by taking all these into account, there is no “global” priority that can easily be displayed. See this post for more info: viewtopic.php?f=156&t=8642&p=36550&hilit=priority#p36553
If we don’t take those things into account, then a feature like this is pretty straightforward, although I’m not sure how practical it would be considering it’s unlikely that the order you see in this list will not match the order in which the jobs actually render. As it currently stands, you could sort by job priority in the current job list, and then use the job right-click script called “PriorityOffset” to adjust priority of the selected jobs. While not as elegant as the drag & drop system, perhaps it’s something you could make use of for now.
Thanks Ryan. I realize the execution order of the jobs would ultimately be dependent on several factors, but the basic scenario I’m thinking of assumes a list of jobs that are all in the same pool/group.
The ultimate solution I’m envisioning is a list showing all jobs, but when jobs are reordered, their priorities are adjusted relative to the nearest jobs in the same pool/group (if that makes sense), as opposed to just the closest jobs in the list period. Thus, you would always have a concept of queueing jobs manually, regardless of the other criteria they depend on, and the fact that they may not execute in the order displayed. A simpler solution for this might be to limit the list to only display and operate on a single pool/group combination.
Basically, on a hypothetical farm with no pools or groups, one job type, no blacklists/whitelists, etc. the jobs would run in the order shown in this view (unless a running job’s priority is dropped in the middle of execution and the job is not interruptable).
Does this give you a better idea of what I’m interested in?
Yeah, that makes sense. If all you’re concerned about is priority within the same pool, then a limitation to only operate within one pool at a time would work. We don’t have to worry about groups so much in this case, since they don’t play a role when it comes to priority.
We’ll put this on the wish list, although this will probably fall outside the scope for what we want to do for 6.1.