HPC clusters and supercomputers resources are accounted in either corehours or nodehours (and more generally CPUhours). One corehour is equal to one core used for one wallclock hour computed from the time the core is allocated to the time it is deallocated.
The total resource available is computed by multiplying the total amount of nodes available for computations by the total allocation time in hours. For instance, a 400node cluster will provide 400*24*365 = 3'504'000 nodehours over one year.
Users are typically given a percentage of the total resource, which has a nodehours equivalent. For instance, 10% of the HPC cluster means 40node hours over 1 year = 350'400 nodehours.
use workload manager to dispatch jobs. Resources
The fairshare algorithm in SLURM is described at http://slurm.schedmd.com/fair_tree.html.
Info 

SCITAS machines have a halflife of one week. 
To see the share for your group you can use the "Sshare" command"
...
SCITAS machines use the SLURM workload manager in order to schedule users’ jobs. In particular, SLURM arbitrates the jobs’ queue contention by using a fairshare algorithm in order to prioritize jobs and ensure that the users’ usage matches their share as much as possible. In particular, SCITAS clusters use a particular flavor of the fairshare algorithm called fairtree.
In order to check their priority, the Sshare command is available on any SCITAS cluster. A typical output will be as follow:
$ Sshare
Account User Raw Shares Norm Shares
...
Raw Usage
...
Norm Usage Effectv Usage FairShare
...
Level
...
FS
...
        
...
scitasge
...
1 0.007752
...
1376 0.000003
...
0.000005
...
1468.763590
...
scitasge aubort
...
1 0.043478
...
0 0.000000
...
0.000000
...
0.290000 inf
...
scitasge clemenco
...
1 0.043478
...
0 0.000000
...
0.000000
...
0.290000
...
inf
scitasge cubuk
...
1 0.043478
...
0 0.000000
...
0.000000
...
0.290000
...
inf
scitasge culpo
...
1 0.043478
...
0 0.000000
...
0.000000
...
0.290000
...
inf
scitasge degiorgi
...
1 0.043478
...
0 0.000000
...
0.000000
...
0.290000
...
inf
scitasge eroche
...
1 0.043478
...
344 0.000001
...
0.250000
...
0.253333
...
0.173913
...
scitasge nvarini
...
1 0.043478
...
0 0.000000
...
0.000000
...
0.290000
...
inf
scitasge qubit
...
1 0.043478
...
351 0.000001
...
0.255072
...
0.250000
...
0.170455
...
scitasge rezzonic
...
1 0.043478
...
681 0.000001
...
0.494928
...
0.246667
...
0.087848
...
scitasge richart
...
1 0.043478
...
0 0.000000
...
0.000000
...
0.290000
...
inf
scitasge rmsilva
...
1 0.043478
...
0 0.000000
...
0.000000
...
0.290000
...
inf
scitasge sue
...
1 0.043478
...
0 0.000000
...
0.000000
...
0.290000
...
inf
scitasge topf
...
1 0.043478
...
0 0.000000
...
0.000000
...
0.290000
...
...
inf
The value used to decide the priority of a job is the "Level FS". The higher the Level FS, the higher the priority. Level FS is the ratio of "Norm Shares" and "Effectv Usage" values, therefore a Level FS of less than 1 represents an overconsumption and more than 1 represents an underconsuming.
In this formula, the "Norm Shares" is the percentage of the cluster which is allocated to the account and the shares are in terms of coreswhereas “Effectv Usage” augments the normalized usage (the users' raw usage normalized to the total number of cpuseconds of all jobs run) to account for usage from sibling accounts for usage from sibling accounts. Within a group all users have equal weight and so 1 share each. The value used to decide the priority of a job is the "Level FS" and this is calculated based on the difference between the "Norm Shares" and "Effectv Usage" values. The higher the Level FS, the higher the priority.
More informations about SLURM, fairshare and fairtree can be found here:
https://slurm.schedmd.com/overview.html
https://slurm.schedmd.com/priority_multifactor.html
https://slurm.schedmd.com/fair_tree.html
Related articles
Content by Label  


...