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

Re: [Condor-users] Better control over negotiator?



On Feb 8, 2008, at 6:14 AM, Steffen Grunewald wrote:

I've got a bunch of (theoretically) identical machines (dual core ones), and have set aside a few of them which only advertise a single slot, to
allow for bigger jobs.
I have also defined

NEGOTIATOR_PRE_JOB_RANK = ( -1 * TARGET.Memory )

to discourage usage of these machines by "small" jobs.
Unfortunately, there seems to be another ranking in effect which is based on other characteristics (for historical reasons, some users still have
a RANK=MIPS in their submit files). Sometimes, when the pool is almost
idle, the "big" slots are taken nevertheless. (seen with 6.9.5, confirmed
with 7.0.0)

In the NEGOTIATOR_PRE/POST_JOB_RANK expressions, TARGET refers to the job ad and MY refers to the machine ad. If you use MY.Memory, you should get the behavior you want.

I can also see (now, with 7.0.0) that slots are matched in pairs: if one
slot of the dual-slot machines is taken, the other one would be, too.
I suppose this is due to the rank value being identical for slots on the
same machine?

Since your pre-job rank isn't sorting anything, the jobs' rank of 'MIPS' will cause this behavior.

Is there a way to read out the actual value of NEGOTIATOR_PRE_JOB_RANK
from an individual slot?


condor_status -format "%d" <rank expression> <slot name>

Any attributes prefixed with TARGET will be undefined. Make sure to quote or escape the rank expression to prevent the shell from evaluating characters like '*'.

+--------------------------------+-----------------------------------+
|           Jaime Frey           | I used to be a heavy gambler.     |
|       jfrey@xxxxxxxxxxx        | But now I just make mental bets.  |
| http://www.cs.wisc.edu/~jfrey/ | That's how I lost my mind.        |
+--------------------------------+-----------------------------------+