LSF Version 7.3 - Administering Platform LSF

Using Historical and Committed Run Time
320 Administering Platform LSF
◆ Historical run time decay
◆ Committed run time
Historical run time decay
By default, historical run time does not affect the dynamic priority. You can
configure LSF so that the user’s dynamic priority increases gradually after a job
finishes. After a job is finished, its run time is saved as the historical run time of the
job and the value can be used in calculating the dynamic priority, the same way LSF
considers historical CPU time in calculating priority. LSF applies a decaying
algorithm to the historical run time to gradually increase the dynamic priority over
time after a job finishes.
Configure historical
run time
1 Specify ENABLE_HIST_RUN_TIME=Y in lsb.params.
Historical run time is added to the calculation of the dynamic priority so that
the formula becomes the following:
dynamic priority = number_shares / (cpu_time * CPU_TIME_FACTOR + (historical_run_time
+ run_time) * RUN_TIME_FACTOR + (1 + job_slots) * RUN_JOB_FACTOR)
historical_run_time—(measured in hours) of finished jobs accumulated in the
user’s share account file. LSF calculates the historical run time using the actual
run time of finished jobs and a decay factor such that 1 hour of recently-used
run time decays to 0.1 hours after an interval of time specified by
HIST_HOURS in lsb.params (5 hours by default).
How mbatchd
reconfiguration
and restart affects
historical run time
After restarting or reconfiguring mbatchd, the historical run time of finished jobs
might be different, since it includes jobs that may have been cleaned from
mbatchd
before the restart.
mbatchd restart only reads recently finished jobs from
lsb.events, according to the value of CLEAN_PERIOD in lsb.params. Any jobs
cleaned before restart are lost and are not included in the new calculation of the
dynamic priority.
Example The following fairshare parameters are configured in lsb.params:
CPU_TIME_FACTOR = 0
RUN_JOB_FACTOR = 0
RUN_TIME_FACTOR = 1
Note that in this configuration, only run time is considered in the calculation of
dynamic priority. This simplifies the formula to the following:
dynamic priority = number_shares / (run_time * RUN_TIME_FACTOR)
Without the historical run time, the dynamic priority increases suddenly as soon as
the job finishes running because the run time becomes zero, which gives no chance
for jobs pending for other users to start.
When historical run time is included in the priority calculation, the formula
becomes:
dynamic priority = number_shares / (historical_run_time + run_time) *
RUN_TIME_FACTOR)
Now the dynamic priority increases gradually as the historical run time decays over
time.