[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Condor-users] negotiation algorithm with dynamic provisioning
- Date: Fri, 12 Nov 2010 16:47:43 -0700
- From: Jon May <jmay@xxxxxxx>
- Subject: [Condor-users] negotiation algorithm with dynamic provisioning
I'm interested in how the negotiation cycle works when condor is configured
for dynamic provisioning. This is for condor version 7.4.2.
According to the description of negotiation in section 3.4.5 of the manual,
at the beginning of the cycle, a list of resources is created, and then when
a machine is found to match a job, that machine is taken out of the list of
(Before going forward I should note that I am a little fuzzy on the terms
"resources" and "machines", which are used in a seemingly interchangeable
way in this section. I have been assuming both terms may be interpreted as
"slots". This may in fact be a crucial misunderstanding, as seen below.)
By my understanding of dynamic provisioning as described in section
126.96.36.199, slots are advertised with their total available cpu, ram, and
disk, and when a job is assigned to a slot, a dynamic slot is created from
the "real" slot to run the job. The "real" slot then advertises its
remaining resources (those not assigned to the dynamic slot).
Based on these two (possibly faulty) understandings, and barring any change
to the way the negotiation cycle works in dynamic provisioning, I assume
that the resource list created at the beginning of negotiation comprises the
"real" slots, and when a match is made to a slot, a dynamic slot is created,
but the real slot is removed from the resource list. Thus, in a single
negotiation cycle, resources can only be taken from a single (real) slot at
Here is an example to illustrate this. The cluster consists of two machines,
A and B, each with 2 cpus, 2gb ram, and 2gb disk, and each with one slot,
configured for dynamic provisioning, advertising all resources. A single
user puts two jobs on the queue, X and Y, each requesting 1 cpu, 1gb ram,
and 1gb disk. There are no other users, running jobs, etc., and all jobs can
run on all slots with equal rank. It is my understanding that in the first
negotiation cycle, X will be assigned to slot1.1@A and Y will be assigned to
slot 1.1@B (or vice versa), and thereafter slot1@A and slot1@B will each
advertise 1 cpu, 1gb ram, 1 gb disk. Specifically, it will *not* be the case
that, e.g. X will be assigned to slot1.1@A and Y will be assigned to slot
1.2@A, and thereafter slot1@A advertises 0 cpu, 0 ram, 0 disk, and slot1@B
advertises 2 cpu, 2gb ram, 2gb disk.
Are my assumptions and descriptions of the negotiation cycle's behavior and
my example correct? Did I make an error or is there undocumented behavior
(or documented behavior I failed to unearth)? Is it possible to configure a
currently released version of condor so that the behavior is more like that
described at the end of my example?
thank you very much, and apologies a priori for misunderstandings; I am
fairly new to the condor game and appreciate the considerable work that has
been done in providing this very powerful software!
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us.
SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK.