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

Re: [HTCondor-users] Filling pool breadth-first with partitionable slots

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.


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.


On 10/31/2016 10:02 AM, Tom Downes wrote:
On the negotiator, I'd do something like this:


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