Q. How does the LSF batch system schedule jobs?

A. The batch system uses a priority scheme to schedule jobs.
   Users are assigned priorities for each queue. When a job
   slot becomes available the scheduler examines all of the runnable
   jobs for the queue and runs the longest waiting job belonging
   to the user with the highest priority. Priorities are adjusted
   periodically based on recent queue usage. The scheduling for one
   queue is independent of the scheduling for all the other queues.

   The current priorities for a queue are listed near the end of
   the output for the "bqueues -l queue" command. For example:

   twister:~> bqueues -l p4-long
    ...
   SCHEDULING POLICIES:  FAIRSHARE  NO_INTERACTIVE
   USER_SHARES:  [default, 1] 

   SHARE_INFO_FOR: p4-long/
   USER/GROUP   SHARES  PRIORITY  STARTED  RESERVED  CPU_TIME  RUN_TIME
   user1           1       0.333      0        0         0.0        0
   user2           1       0.333      0        0         0.0        0
   user3           1       0.333      0        0         0.0        0
   user4           1       0.333      0        0        29.4        0
   user5           1       0.316      0        0       821.9        0
   user6           1       0.150      0        0     18781.0        0
   user7           1       0.143      1        0      2288.2     2696
   user8           1       0.062      0        0     67178.7        0
   user9           1       0.032      3        0     34856.3    65633
   user10          1       0.030      0        0    158440.7        0
   user11          1       0.028      4        0     73265.0    33534
   user12          1       0.025      1        0    100969.1    70430
   user13          1       0.025      2        0     52842.4   103421
   user14          1       0.016      0        0    305000.0        0
   user15          1       0.014      3        0     91714.2   211038
    ...

   The meaning of each column is:

   SHARES    This is always 1 for our configuration.

   STARTED   The number of jobs that this user is running in this queue.

   RESERVED  This is always 0 for our configuration.

   CPU_TIME  Not used by the scheduler.

   RUN_TIME  The user's historical runtime in this queue. This is computed
             as the integral over time of the the number of job slots in
             use by the user multiplied by an exponential with a decay
             constant such that an hour accumulated now contributes the same
             amount as 10 hours accumulated 10 hours ago. It is measured
             in seconds.

   The PRIORITY is computed by the formula:

   1 / PRIORITY = 3.0 + 
                  0.7 * (RUN_TIME / 3600) +
                  3.0 * (STARTED)

   Notice that the PRIORITY, and therefore the scheduling algorithm,
   does NOT depend on how long a user's jobs have been waiting in
   the queue. This means that you should not be discouraged from
   submitting a job to a queue which already has a large number of
   jobs waiting. If you haven't used the queue recently you will
   have a high priority and your job will run soon. Conversely,
   if you have been using a queue very heavily, other users'
   jobs may run ahead of your's.
 
   Overall, this scheduling algorithm produces a much fairer sharing
   of resources than a simple FIFO scheduling algorithm.


   9/11/06 dugan