Re: [HTCondor-users] Multiple negotiators : which one wins?

[Jeff Templon <templon@xxxxxxxxx>]

Hi Christoph,

I know how to do the constraints, thatâs not the problem.  The problem is, if I have jobs that could conceivably run on both sets of slots (set A feeding thru negotiator A, set B through negotiator B), is there any way to effectively tell them, âif both are possible, choose Aâ?  As far as I can tell, this is not possible through ranking, as the negotiators do not talk to each other and each negotiator handles only its own slots.

This agrees with Maxâs answer, that there is no way really via the rank itself.  We are going to proceed by using some variants of the âdelayâ idea.

Thanks

JT


> On 9 Dec 2024, at 12:53, Beyer, Christoph <christoph.beyer@xxxxxxx> wrote:
> 
> Hi,
> 
> you can tag the slots and jobs or use any of the existing classadds and feed them to: 
> 
> NEGOTIATOR_JOB_CONSTRAINT & NEGOTIATOR_SLOT_CONSTRAINT
> 
> e.g. 
> 
> GPU_NEGOTIATOR.NEGOTIATOR_JOB_CONSTRAINT = (RequestGpus =!= UNDEFINED && RequestGpus >= 1)
> 
> The same way you should exclude these slots and jobs from the other negotiator 
> 
> You need some additional syntax if both negotiators run on the same machine: 
> 
> GPU_NEGOTIATOR = $(NEGOTIATOR)
> GPU_NEGOTIATOR_ARGS = -local-name gpu_negotiator
> DAEMON_LIST = $(DAEMON_LIST) GPU_NEGOTIATOR
> 
> 
> 
> Best
> christoph
> 
> -- 
> Christoph Beyer
> DESY Hamburg
> IT-Department
> GPU_NEGOTIATOR.NEGOTIATOR_JOB_CONSTRAINT = $(IS_JUPYTER_JOB) =?= false &&  (RequestGpus =!= UNDEFINED && RequestGpus >= 1)
> Notkestr. 85
> Building 02b, Room 009
> 22607 Hamburg
> 
> phone:+49-(0)40-8998-2317
> mail: christoph.beyer@xxxxxxx
> 
> ----- UrsprÃngliche Mail -----
> Von: "Max Fischer, SCC" <max.fischer@xxxxxxx>
> An: "HTCondor-Users Mail List" <htcondor-users@xxxxxxxxxxx>
> Gesendet: Montag, 9. Dezember 2024 12:44:28
> Betreff: Re: [HTCondor-users] Multiple negotiators : which one wins?
> 
> Hi Jeff,
> 
> From back when we accidentally had two negotiators (someone broke our HA setupâ *whistles innocently*) in practice there is a first come first serve for the negotiators. Each negotiator will do its regular cycle independently, ask the Schedds for jobs, and schedule whatever it can. Whichever Negotiator asks a Schedd second only gets the leftovers. For all intents and purposes the order is random.
> 
> Iâm not aware of any mechanism to have two negotiators actually cooperate. The best I can see is to manually adjust the NEGOTIATOR_XYZ_JOB_RANK expression of each negotiator to prefer those jobs it can handle well and delay those others handle better. Still, if you get only one kind of job then both negotiators will grab them with the same priority.
> 
> Cheers
> Max
> 
>> On 9. Dec 2024, at 12:12, Jeff Templon <templon@xxxxxxxxx> wrote:
>> 
>> Yo,
>> 
>> How do multiple negotiators work at the innards level?  Suppose we have two negotiators, each that covers half of the pool.  Both have the same ranking expressions.  A job is submitted that could run anywhere in the pool, so both negotiators could in principle deal with it.  What determines which one wins?
>> 
>> Does the job get given to only one negotiator for matching, or to both?  Suppose one negotiator is on a slower machine than the other, will that make a difference? Suppose I change the rank expression on one of the negotiators so for that job, the changed negotiator will report a higher rank for the job than will the other negotiator, will the changed one always win?  Or does the rank only matter internal to the negotiator, the job doesnât get a chance to say âthis negotiator gave a higher rank then this other one, highest rank wins?â
>> 
>> Iâm trying to correct an adverse consequence of our negotiator setup using ranking.  Since there is no node overlap between the negotiators, it seems that ranking is the only tool I have, but Iâm not sure it makes a difference between negotiators, hence the question.
>> 
>> JT
>> 
>> 
>> _______________________________________________
>> HTCondor-users mailing list
>> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
>> subject: Unsubscribe
>> 
>> The archives can be found at: https://www-auth.cs.wisc.edu/lists/htcondor-users/
> 
> 
> _______________________________________________
> HTCondor-users mailing list
> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
> 
> The archives can be found at: https://www-auth.cs.wisc.edu/lists/htcondor-users/
> 
> _______________________________________________
> HTCondor-users mailing list
> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
> 
> The archives can be found at: https://www-auth.cs.wisc.edu/lists/htcondor-users/