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

Re: [Condor-users] about negotiator and scheduler


Thanks for your reply.
I think I have made some mistake in the concept. (very confused in my mind).

> What do you mean "rejected the works"? If a job is not matched in a
> negotiation cycle, then it stays in the queue.

Actually, I am wondering if there are more than one schedd and negotiator
exist in the clusters. Then will there be any contention on the resources.
e.g. schedd A think the job match to resource C and schedd B also think
another job match resource C.

> What do you mean by 'scheduler'? "Scheduling" in condor is really split
> between two daemons.
> 1. The condor_schedd - this daemon maintains the job queue. If it is
> told _exactly_ where to run the job (ie with Condor-G, with
> globusscheduler = some.machine.com/jobmanager), it can immediately
> start running the job.
> 2. The condor_negotiatior (and to an extent, the condor_collector) -
> this daemon is the "matchmaker" - and it sort of is the "scheduler" for
> a pool. There is only one negotiator per pool.
> You really can't ask about the "schedulers" in Condor, because it's a
> vague notion.

What I mean here is that, does Condor-G also use the same matching
mechanism as that of condor in selecting a site to submit jobs. i.e. Since
there may have different users jobs queued inside the schedd of condor-g.
How it decides which grid site to submit? who jobs will be submit first?
Does it need to negotiate with the grid site before submitting by
negotiator ? etc.

>> One more question about machine definition in condor, it will only
>> match one job to a cluster at each negotiaton cycle, right? How's the
>> case for condor-g?
> A "cluster" in Condor means a collection of jobs in the schedd (ie a
> "cluster of 100 jobs, from 'queue 100' in a submit file). Condor will
> keep matching jobs in that cluster so long as it can find resources  for
> it. There is no difference for matchmaking in Condor or Condor-G,  in
> terms of matching per cluster.
> The one real difference between matchmaking in Condor and Condor-G is
> that there is no claiming protocol in Condor-G. In regular Condor, when
> we match a job to a resource, the ad for the resource gets removed from
> the collector, and we don't match it to a different job in the next
> negotiation cycle. Since there's no claiming in Condor-G, if you're  not
> careful you can match the same resource many times, if you can't get rid
> of the ad in the condor_collector for that resource.
Actually this is a typing mistake. Here I would like to know "Machine"
instead of "Cluster", but seems that the questions have been answered for

Thanks very much for your patient in answering my questions,