The LSF is configured to use a so-called cross-queue fairshare policy. The amount of computing resources your jobs will get, is mainly determined by the share value of your cluster group. The share value has a relative meaning, i.e. the absolute value is not important. What matters, is the ratio between the values assigned to different cluster groups. The share value, that remains constant over time, is used to compute a dynamic priority value.
The priority value considers the cpu time, run time and job slots used by the cluster group. At the moment, one job slot corresponds to one core. High cpu time, run time and job slot usage negatively influence the priority value. Cpu time, run time and job slots may be weighed by some factors, that can be configured in /lustre/soft/x86_64/lsf/conf/lsbatch/tuegrid/configdir/lsb.params by the LSF administrator. Currently, the default configuration is used in lsb.params, which means, that there is no weighting. The runtime and job slot values refer to running jobs only. The cpu time is accumulated over time.
When running jobs, the dynamic priority decreases gradually until any job of the cluster group completes. Then it increases immediately. However, it does not return to the initial priority value directly, because of the accumulated cpu time. The accumulated cpu time will be decaying gradually: 1 hour of recently-used CPU time decays to 0.1 hours after an interval of time specified by HIST_HOURS in lsb.params (5 hours by default).
It is possible, to configure different share values for different queues. At the moment, the share value is the same for all queues (as is your dynamic priority).
Some cluster groups get special share values, because they contributed to the cluster financially:
All other cluster users have a share value of 105,000. This value may seem very high, when compared to the values above. However, these shares have to be distributed among a great number of users.
Besides dynamic priority, a queue priority may influence the amount of computing resources as well. However, it is only considered, if two users from the same cluster group are competing for resources:
Besides having different priorities, queues also may be PREEMPTIVE. Jobs in such queues may preempt jobs in lower priority queues. At present, the MPI queue is PREEMPTIVE to the queues NORMAL, EXTRALONG and VERYSHORT, meaning that jobs from this queue may preempt jobs in NORMAL, EXTRALONG and VERYSHORT. In other words, MPI queue has priority over all other queues (except the 15 min. test queue SHORT) regardless of any dynamic priority based on shares.