Configuring committed run time
Procedure
dynamic priority = number_shares / (cpu_time * CPU_TIME_FACTOR + (historical_run_time + run_time) * RUN_TIME_FACTOR + (committed_run_time - run_time) * COMMITTED_RUN_TIME_FACTOR + (1 + job_slots) * RUN_JOB_FACTOR + fair_share_adjustment(struct* shareAdjustPair)*FAIRSHARE_ADJUSTMENT_FACTOR) + ((historical_gpu_run_time + gpu_run_time) * ngpus_physical) * GPU_RUN_TIME_FACTOR
where committed_run_time is the run time requested at job submission with the -W option of bsub, or in the queue configuration with the RUNLIMIT parameter. This calculation measures the committed run time in hours.
In the calculation of a user’s dynamic priority, COMMITTED_RUN_TIME_FACTOR determines the relative importance of the committed run time in the calculation. If the -W option of bsub is not specified at job submission and a RUNLIMIT has not been set for the queue, the committed run time is not considered.
COMMITTED_RUN_TIME_FACTOR can be any positive value between 0.0 and 1.0. The default value set in lsb.params is 0.0. As the value of COMMITTED_RUN_TIME_FACTOR approaches 1.0, more weight is given to the committed run time in the calculation of the dynamic priority.
Example
The following fair share parameters are configured in lsb.params:
CPU_TIME_FACTOR = 0
RUN_JOB_FACTOR = 0
RUN_TIME_FACTOR = 1
FAIRSHARE_ADJUSTMENT_FACTOR = 0
GPU_RUN_TIME_FACTOR = 0
COMMITTED_RUN_TIME_FACTOR = 1
Without a committed run time factor, dynamic priority for the job owner drops gradually while a job is running:
When a committed run time factor is included in the priority calculation, the dynamic priority drops as soon as the job is dispatched, rather than gradually dropping as the job runs: