Platform LSF Administration Guide Version 6.2

Chapter 16
Fairshare Scheduling
Administering Platform LSF
303
Using Historical and Committed Run Time
By default, as a job is running, the dynamic priority decreases gradually until the job has
finished running, then increases immediately when the job finishes.
In some cases this can interfere with fairshare scheduling if two users who have the same
priority and the same number of shares submit jobs at the same time.
To avoid these problems, you can modify the dynamic priority calculation by using either
or both of the following weighting factors:
◆ 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.
Configuring
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
The 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)