Re: [HTCondor-users] Usage of JobStart or ActivationTimer in startd RANK expression?

[Jaime Frey <jfrey@xxxxxxxxxxx>]

On Apr 3, 2020, at 4:38 PM, Jaime Frey <jfrey@xxxxxxxxxxx> wrote:

On Apr 2, 2020, at 4:32 AM, Carsten Aulbert <carsten.aulbert@xxxxxxxxxx> wrote:

To further complicate the matter:

* interactive jobs:
* for testing purposes, users may submit interactive jobs (can the
number and run time be limited?)
* these may request a number of GPU and CPU resources (obviously
within the limits of available machines)
* due to their interactive nature, these jobs should be matched as
quickly as possible, without breaking the guaranteed runtime rules above
* CPU-only jobs should only match against non-GPU hosts

You can use submit requirements and submit transforms to constrain the interactive jobs.
You can reject interactive jobs that request too much time, or silent cap the time requested.
You can also add attributes to tag the interactive jobs as special to make matchmaking easier.

On our local CHTC pool at UW-Madison, we run a second negotiator that only matches interactive jobs, whose negotiation cycle can be much faster than the main negotiatorâs. We use a submit transform to put interactive jobs in a separate accounting group and have the second negotiator only match jobs from that accounting group (a new feature coming in 8.9).

One more thing I forgot to mention. You can use concurrency limits to limit the number of interactive jobs that can run. These are pool-wide virtual resources that jobs can request, assigned by the negotiator. You would use submit transforms to have interactive jobs request a concurrency resource. In the negotiatorâs configuration, you define the different concurrency resource names and the number available for each. You can declare that all resource names that start with a given prefix have a chosen amount available without explicitly naming each one. Thus, you can set per-user limits without having to give each username.

 - Jaime