[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] about multiple scheduler issues
- Date: Mon, 21 Feb 2005 15:59:13 +0800 (HKT)
- From: "Carson Hung" <carson@xxxxxxxxxxxxxx>
- Subject: Re: [Condor-users] about multiple scheduler issues
One more question to ask, where can I find the USCMS writeup :)
> 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.
> I have more understanding about the condor and condor-g
>> On Sat, Feb 19, 2005 at 04:40:24PM +0800, Carson Hung wrote:
>>> 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
>> since the last one. That usually is good enough.
>> 2. The startd can detect if it's been matched twice, and can
>> 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.
>> Condor-users mailing list
> Condor-users mailing list