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

Re: [Condor-users] about multiple scheduler issues



http://www.cs.wisc.edu/condor/USCMS_matchmaking.html

Carson Hung wrote:

>Hi Erik,
>
>One more question to ask, where can I find the USCMS writeup :)
>
>Thanks,
>Carson
>
>  
>
>>Hi Erik,
>>
>>Thanks very much for your clear explanation.
>>
>>You are right, I am actually asking if it is possible to have more than
>>one negotiators with multiple schedulers. Since I think that case is
>>possible to exist in condor-g environment.
>>
>>and I think you have answered my questions. Really thanks a lot.
>>
>>Thanks,
>>Carson
>>
>>
>>I have more understanding about the condor and condor-g
>>
>>    
>>
>>>On Sat, Feb 19, 2005 at 04:40:24PM +0800, Carson Hung wrote:
>>>      
>>>
>>>>Hi,
>>>>
>>>>Since it is possible to have more than one schedulers/submittors in
>>>>the clusters.
>>>>So I would like to know if it is possible that 2 or more schedulers
>>>>match the same resource to the different jobs if they come from
>>>>different schedulers/submittors.
>>>>
>>>>        
>>>>
>>>I think you really mean "if it is possible that 2 or more negotiators
>>>match the same resources to different jobs if they come from different
>>>schedds" - you can't use the term 'scheduler' twice :)
>>>
>>>In Condor, it's not really possible for the negotiator to match a
>>>resource twice, because:
>>>
>>>A. There's only one negotiator, so it will only match a resource once
>>>per neogotiaition cycle.
>>>
>>>B. It is possible for a resource to be matched twice - if it gets
>>>matched in one negotiation cycle, but doesn't update the collector
>>>before the next  negotiation cycle starts. We prevent this from
>>>happening in two ways:
>>>   1. The negotiation CANNOT start until at least 20 seconds have
>>>passed
>>>since the last one. That usually is good enough.
>>>   2. The startd can detect if it's been matched twice, and can
>>>recover,
>>>if the 20 seconds wasn't good enough.
>>>
>>>In Condor-G, because there is no claiming (ie the resource doesn't
>>>automatically tell the collector that it is no longer able to be
>>>matched), matching twice is more of a problem. We ususally build-in
>>>some sort of  claiming when we've deployed matchmaking in the past
>>>(see the USCMS writeup I pointed you at eariler).
>>>
>>>If you advertise your resource to more than one collector/negotiator,
>>>then matching twice is a real problem. In regular condor, it's not
>>>possible for a startd to report to two different collectors, so it's
>>>not a problem.
>>>
>>>-Erik
>>>_______________________________________________
>>>Condor-users mailing list
>>>Condor-users@xxxxxxxxxxx
>>>https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>>>      
>>>
>>
>>_______________________________________________
>>Condor-users mailing list
>>Condor-users@xxxxxxxxxxx
>>https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>>    
>>
>
>
>
>_______________________________________________
>Condor-users mailing list
>Condor-users@xxxxxxxxxxx
>https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>  
>