[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-users] What are the possible priority values?



On 8/24/05, newhorizon@xxxxxxx <newhorizon@xxxxxxx> wrote:
> What are the possible priority values?

prior to the 6.7.x release (sorry can't remember the x but it is one
of the more recent ones - search the archive for it if you like or
look at the release history page)
+20 to -20 in int increments defaulting to 0.

after this it is basically an int so 32 bit signed integer - +/-
2Billion should cover you I should think...

> And would it make sense to mention this range of
> values in the condor_prio documentation?
> http://www.cs.wisc.edu/condor/manual/v6.7/condor_prio.html
> 
> Permit me to offer a bit of related miscellaneous feedback...
> IMHO, it's a bit confusing to have "higher numbers
> corresponding to greater priority" (quoting the above URL),
> but "A lower numerical value for user priority means higher
> priority..." (Manual sec 2.7.2).
> 
> In sec 2.6.4, and in the context of condor_prio, we read
> "For example, to change the priority of a job to -15...".
> Is the assumption that the reader has first read
> the condor_prio.html page?  I humbly submit that that's not
> a safe assumption, and the user is as often as not
> able to understand what it means to change the priority
> to -15.
> 
> FWIW....HTH....

The condor priority model is somewhat confusing. sadly there are
multiple different 'ranking' systems in condor with similar names to
heighten the problem.

Their is the user_prio which reflects a users admin assigned ability
to take and hold claims to machines relative to other people. This can
auto adjust over time via the priority half life.

There is the job priority which is set on a per job basis and
basically affects the order in which the schedd presents the jobs to
negotiator (which is important due to RANK below)

There is the RANK as defined by the startd which overrides all other
priorities (which means you should be careful in setting your job
priorities that they reasonably match with the RANK given by the
machines else you will end up preempting yourself)

There is the RANK your job uses to rate machines it runs on - I find
that if you have significant differences in how machines RANK jobs it
is better to not play with job RANKs too much since you can end up
with disconnects in relative rankings causing unwanted preemption.

I do not know what description the condor team use but I tend to try
to always use

startd defined RANK = "Machine Rank"
job specified RANK = "Job RANK"
user priority            = "User priority" // I block this entirely so
rarely use it
job defined priority  = "Job priority"

Keeping to a well defined nomenclature helps immensely

In fact in general it is best in well constrained pools (like calc
farms) to limit your use of these methods to a couple (or if you are
using machine RANK just one)

This is an unfortunate reality of a massively configurable system
where you have competing demands and no central authority driving the
overall 'queue'. Accepting this and dealing with it as best you can
via some overarching control is probably best.

For more distributed ad hoc pools this advice probably doesn't hold
true YMMV EAOE etc etc...

Matt