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

Re: [HTCondor-users] Job cluster user priorities



User priority applies to a user, not specific jobs of that user. It adjusts continuously (well, updates every negotiation cycle) to reflect how many resources the user has used recently. The general goal is that a user who has used few or no resources recently should get a larger share of the pool.

In your scenario, the user who waits before submitting a large cluster of jobs will initially get a larger share of the pool. But they didnât get any work done while they waited, and as their workload continues to run, their priority will worsen and their share of the pool will slowly decrease.

 - Jaime

> On Nov 14, 2024, at 3:45âAM, Thomas Hartmann <thomas.hartmann@xxxxxxx> wrote:
> 
> Hi all,
> 
> AFAIS all the jobs in a cluster are weighted by the user's job priority at the moment of the submission, or?
> This caused a bit ill humour between some of our users - as apparently one of them had figured out to use the behaviour to their advancement. I.e., they had been waiting for their prio to reach a advantageous level wrt their colleagues and then submitting a very large cluster - so that all jobs could profit from the initial good priority even if the actual job starts are spread over several days.
> 
> Question would be, if there is a way to weight a cluster job by the user's weight at the moment of the actual job being negotiated?
> 
> Alternatively, would maybe late materialization behave more gracefully, with the iterator realizing a job with the negotiation applying the then current prio, or?
> I.e., would forcing all job clusters to be late materialized (if possible??) a way to go? ð
> 
> Cheers and thanks for ideas,
> Thomas