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

[Jaime Frey <jfrey@xxxxxxxxxxx>]

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