Fairshare
In order to ensure the fairest possible use of the cluster for all users, we use the fairshare policy in prioritizing jobs. All projects on the cluster are equal. The measure of use (consumption factor) of a computer cluster is the product of the number of requested processor cores and the time these cores spend occupied (ncpus x walltime). This policy does not take into account the utilization of the requested cores, but looks at whether they are available to other users. It is up to the user to ensure that their job uses as high a percentage of the allocated cores as possible.
PBS uses the term "priority" as a job parameter and is not the same as the term used in this documentation. The priority parameter visible with the qstat command is always set to 0 and is used for purposes other than cluster-level prioritization. Management of this parameter is disabled for users.
Using the consumption factor of all jobs within the project (U_i) we get the total use of that project (U_p) and from it we can calculate the share of consumption in relation to the rest of the users (projects). It should be emphasized that the fairshare system at Supek does not look at the consumption of an individual, but only of the project as a group, and the priority is calculated for all members of the group based on the same consumption factor.
U_i=ncpus_i x walltime_i
U_p=sum(U_i)
Fairshare share of the project (FS_p) is calculated as a percentage of the project's consumption in the total consumption on the cluster (U_total).
FS_p = U_p/U_total
Note
PBS does not allow users to view fairshare parameters. We are currently working on enabling insight into the same for members of individual projects.
Half-life
A consumption half-life option is included. Every 168 hours consumption is reduced by a factor of 0.5 (50%).
Priority
The equation for calculating the priority takes into account other parameters besides the fair share share. Currently, the parameters used for job sorting (priority calculation) are the number of requested cores (ncpus), the fair share share (FS_p) and the time spent in the queue (Et).
set server job_sort_formula = 10*(ncpus/6656)+1000*(1-fairshare_tree_usage)+(eligible_time/86400)
P_i = 10 x (ncpus_i/6656) + 1000 x (1 - FS_p) + (Et/86400)
The first part of the formula is the one that increases the priority of large jobs, in order to make them stand out more than small jobs. The second factor increases the priority of jobs whose fair share share is small, and the greatest emphasis is placed on it. The last factor increases the priority of jobs that have spent a long time in the queue.
Note
PBS does not allow sorting jobs according to the priority obtained from the formula. The user can get insight into this parameter using the tracejob command. The parameter is calculated at each scheduling cycle.
Job Scheduling System Options
Strict ordering
The strict ordering option ensures that jobs with a higher priority are executed first and thus prevents the "pushing" of jobs with a lower priority, but also with smaller resource requirements, in front of jobs that require a larger amount of resources and have a higher priority.
Queue priorities
There are several queue categories on the Supek computer cluster, and these different categories have different priorities.
The row categories are:
- Production queues - 1
- Test queues - 2
- Login queues - 1
Production queues do not have a limit on the amount of resources, and have a higher time limit than test queues. Test queues are designed to prepare jobs for production. You can read more about the limits of the queues themselves on the Job Queues page.
As far as job scheduling is concerned, the difference is that test queues have a higher priority than production queues. This means that when starting jobs, jobs that request a test queue will be filled first, followed by jobs that request production queues.
This action precedes the priority calculation, so the job in the test environment will start executing before the job in the production queue regardless of its calculated priority. Restrictions imposed on the test environment prevent abuse of this option.