[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


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.        |