Re: [Condor-users] When is machine RANK evaluated? Was: Rank expressions not evaluated

[Todd Tannenbaum <tannenba@xxxxxxxxxxx>]

Dan Bradley wrote:
> Hi Carsten,
>
> Machine rank should trump user priority, so it should not be necessary 
> for user B to have a better EUP than user A in the scenario that you 
> describe.

Unfortunately, looking at the source code, it looks like the negotiator
has a subtle bug starting back in v7.3.1 (with the introduction of 
ResourceWeights) that could explain the wrong behavior in Carsten's log 
below.  Carsten, I think you understand correctly what should be 
happening - i.e. in your example user B should get the machine no matter 
what the user priorities are.

We are working to confirm/reproduce the problem to make sure our reading
of the source code is correct, and assuming the problem is as real as it
appears, a patch for the condor_negotiator in v7.6.2.

regards,
Todd


> Do you have NEGOTIATOR_CONSIDER_PREEMPTION set to false?
>
> --Dan
>
> On 6/28/11 7:31 AM, Carsten Aulbert wrote:
> > Hi all
> >
> > essentially this is just a rewrite of Henning's question, but in a 
> > somewhat
> > broader scope:
> >
> > I think we understand the negotiation cycle to some extend, but we 
> > don't know
> > under which circumstances the machine RANK is evaluated. It seems it 
> > will ONLY
> > be evaluated if the effective user priority (EUP) is sufficient to 
> > exceed at
> > least the "fair share quota".
> >
> > At least we discovered that this seems to be true, i.e. user A has an 
> > EUP of
> > 1000 and user B of 100000 and we have 8 slots user A gets all. 
> > However, we
> > want to give user B the possibility to move into certain slots and 
> > hence set
> > the machine RANK to something like this:
> >
> > Rank = IfThenElse(WantGPU =?= true,1000,0)
> >
> > (also with prefix TARGET.)
> >
> > User A does not have this set, should thus have a lower Rank than User 
> > B (me),
> > however, it seems this does not help:
> >
> > 06/28/11 14:25:55 Socket to carsten@xxxxxxxxxxxxxxxx 
> > (<10.20.40.16:35426>)
> > already in cache, reusing
> > 06/28/11 14:25:55     Over submitter resource limit (0.000000, used 
> > 0.000000)
> > ... only consider startd ranks
> > 06/28/11 14:25:55     Sending SEND_JOB_INFO/eom
> > 06/28/11 14:25:55     Getting reply from schedd ...
> > 06/28/11 14:25:55     Got JOB_INFO command; getting classad/eom
> > 06/28/11 14:25:55     Request 00102.00000:
> > 06/28/11 14:25:55 matchmakingAlgorithm: limit 0.000000 used 0.000000 
> > pieLeft
> > 0.000000
> >
> > 06/28/11 14:25:55       Rejected 102.0 carsten@xxxxxxxxxxxxxxxx
> > <10.20.40.16:35426>: fair share exceeded
> >
> > Can I infer from this that RANK is never evaluated unless EUP also is in
> > favor?
> >
> > (We are currently resorting to GROUPs ttrying to resolve this but so 
> > far to no
> > avail)...
> >
> > Anyone who can shed some light what we are doing wrong?
> >
> > Cheers
> >
> > Carsten
> > _______________________________________________
> > Condor-users mailing list
> > To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx with a
> > subject: Unsubscribe
> > You can also unsubscribe by visiting
> > https://lists.cs.wisc.edu/mailman/listinfo/condor-users
> >
> > The archives can be found at:
> > https://lists.cs.wisc.edu/archive/condor-users/
> _______________________________________________
> Condor-users mailing list
> To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
> You can also unsubscribe by visiting
> https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>
> The archives can be found at:
> https://lists.cs.wisc.edu/archive/condor-users/


--
Todd Tannenbaum                       University of Wisconsin-Madison
Center for High Throughput Computing  Department of Computer Sciences
tannenba@xxxxxxxxxxx                  1210 W. Dayton St. Rm #4257
Phone: (608) 263-7132                 Madison, WI 53706-1685