COMSUMPTION_POLICY moves partitionable slot splitting into the negotiator. Otherwise the splitting of the partitionable slot happens in the STARTD as part of the process of
the SCHEDD claiming a slot. (which is why you can only do one per cycle)
The upside of this is that the negotiator can then choose breadth first or depth first without any effect negotiation efficiency.
But the negotiator is also doing more work, so the overall negotiation cycle takes longer.
I would suggest that CONSUMPTION_POLICY makes filling an empty pool with jobs more efficient breadth-first, but makes negotiation less efficient overall over the lifetime of
a long-running pool.
You should keep in mind that the normal case for HTCondor isnât that all of the STARTDs are empty and need to be filled with jobs â the normal case is that every negotiation
cycle, some number of partionable slots are PARTIALLY idle and need to be matched with jobs that fit them.
In a steady-state pool the negotiator will typically only be able to match 1 job per partitionable slot anyway because the partitionable slot is already mostly full. In that
situation CONSUMPTION_POLICIES just makes the negotiator slower because it has to do more work. Unless there are more than a few *empty* partitionable slots to choose from breadth first and depth first scheduling end up doing exactly the same thing
â CONSUMPTION_POLICIES just does that thing in the negotiator.
-tj
From: HTCondor-users [mailto:htcondor-users-bounces@xxxxxxxxxxx]
On Behalf Of Tom Downes
Sent: Wednesday, November 2, 2016 10:51 AM
To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>
Subject: Re: [HTCondor-users] Filling pool breadth-first with partitionable slots
Todd:
The manual (going off 8.5.7) is extremely unclear as to the benefits of CONSUMPTION_POLICY that you describe. As it stands, the macro's definition basically looks like a startd-side rounding mechanism with no implications about scheduling
efficiency.
If you get to p. 383 you see some of the implications but the name CONSUMPTION_POLICY certainly doesn't lead one to conclude "this is a knob that makes scheduling better."
If you poke hard you'll find a release note for 8.2.8 that describes the conflict between CONSUMPTION_POLICY and CLAIM_PARTITIONABLE_LEFTOVERS. Are you asserting that enabling CONSUMPTION_POLICY is the more efficient of the two options?
I read the manual to mean that CLAIM_PARTITIONABLE_LEFTOVERS defaults to True in a way that enables its use out-of-the-box.
Tom Downes
Senior Scientist and Data Center Manager
Center for Gravitation, Cosmology and Astrophysics
University of Wisconsin-Milwaukee
414.229.2678
On Mon, Oct 31, 2016 at 4:22 PM, Todd Tannenbaum <tannenba@xxxxxxxxxxx> wrote:
We are looking for a way to fill our pool breadth first, without the
limitation of only being able to match one job per negotiation cycle
per machine. Does HTCondor have a way to overcome this?
We are using HTCondor 8.4.7. In addition, we are also using
concurrency limits and consumption policy is enabled on all machines
in the pool.
Any help would be greatly appreciated.
Thanks.
Kind Regards, Jason
Hi Jason,
**Because your pool has enabled consumption policy**, I think Tom's suggestion below should enable you to setup depth-first filling and still match many jobs per negotiation cycle per machine. Please let us know how it goes, and assuming it works for you (I
think it will), I will update the HOWTO recipe you referenced on the wiki.
regards,
Todd
On 10/31/2016 10:02 AM, Tom Downes wrote:
On the negotiator, I'd do something like this:
NEGOTIATOR_POST_JOB_RANK = +MY.Cpus
This makes the most favorable match the partitionable slot with the most
CPUs which is what I mean by "breadth first." You can obviously extend
this idea to memory, but you need to scale the memory to CPUs. For me, I
have 2GB of RAM per core so this would be
NEGOTIATOR_POST_JOB_RANK = +MY.Cpus + (MY.Memory / 2048)
--
Tom Downes
Senior Scientist and Data Center Manager
Center for Gravitation, Cosmology and Astrophysics
University of Wisconsin-Milwaukee
414.229.2678
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}