Something that has never been perfectly clear to me, I'd like to get cleared up.
If a NEGOTIATOR_PRE_JOB_RANK sort produces ties the docs say:
Resources that match a request are first sorted by NEGOTIATOR_PRE_JOB_RANK. If there are any ties in the rank of the top choice, the top resources are sorted by the user-supplied rank in the job ClassAd, then by NEGOTIATOR_POST_JOB_RANK, then by PREEMPTION_RANK (if the match would cause preemption and there are still any ties in the top choice).
What is not clear to me here is *what* is being re-sorted here and, to some degree, if any decisions are being made *between* re-sorts. The paragraph that explains the sort behaviour is fairly ambiguous about these aspects.
They way it is written, it makes it sound like the entire list is re-sorted if NEGOTIATOR_PRE_JOB_RANK doesn't yield a unique and that it's re-sorted 2 times, maybe 3 times if preemption is to occur, before another top match is looked for. That doesn't seem like it can be the case. It *must* be looking for a new top match between sorts otherwise the only sort setting that matters after NEGOTIATOR_PRE_JOB_RANK would be the last one evaluated (NEGOTIATOR_POST_JOB_RANK or PREEMPTION_RANK). It bothers me that that isn't clearer in the docs. *What* is re-sorted isn't as easy to reason out from that paragraph.
Is the *entire* machine list re-sorted by job RANK and then checked for a unique top ranked job? Or are just the top, tied machines re-sorted by job RANK?
If that yields no one unique machine are the top, tied machines from the job RANK re-sort then re-sorted by NEGOTIATOR_POST_JOB_RANK and a new top match looked for? Or is the entire machine list that's re-sorted?
The latter approach makes the most sense to me (re-sorting just the ties). But I can see how that might not be the case.
Cycle Computing, LLC
Leader in Open Compute Solutions for Clouds, Servers, and Desktops
Enterprise Condor Support and Management Tools