Mailing List Archives
Authenticated access
|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Condor-users] Condor-G matchmaking
- Date: Tue, 24 Aug 2004 17:08:57 -0400
- From: Gabriel Mateescu <gabriel.mateescu@xxxxxx>
- Subject: [Condor-users] Condor-G matchmaking
Hi,
In order to assure correct matching between
jobs and resources, it would help if one
could put a "hold" on the negotiator.
I am thinking about the following scenario:
1. Two long jobs, each requiring N CPUs
are submitted. Assume the job classad
have both
Requirements = TARGET.FreeCPUS >= N
2. The scheduler triggers a negotiation cycle.
3. There is a resource which has exactly N free
CPUs.
4. Job 1 is matched and will be sent by the
scheduler to the Globus resource.
Say it will reach the resource at time T
5. The resource sends a classad at time t < T
6. The resource classad arrives at the central
manager and -- either because a new job 3 arrives,
or the negotiator interval has elapsed -- a new
negotiation cycle occurs which matches job 2
against the same resource with the N CPUs
(the negotiator is oblivious, and the resource
classad can't know that job 1 is en-route)
Result:
job 2 is incorrectly sent to the resource
whose N CPUs will be allocated to job 1
This can be avoided if one could configure
the negotiator so that after a negotiation
cycle it is put on hold until it receives
a release command.
Is there a way to get this behavior?
Thank you.
Gabriel Mateescu