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

[Todd Tannenbaum <tannenba@xxxxxxxxxxx>]

> 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