In the HPC world, consumption of computing resources is measured in core hours (core-h). As the name suggests, one core-h typically represents the usage of one CPU core for one hour.

This page gives an overview of how computing time can be managed.

Table of Contents

1. Checking the Computing Time Quota
2. Sliding Window Quota
3. Exceeding Computing Time Quotas
4. How to check the Billing of a Job
5. See also

Checking the Computing Time Quota

To review the consumed computing time of the last six months use:

r_wlm_usage

Using the following command allows you to review the usage of a given project by all users involved:

r_wlm_usage -p <project-id>

To check the remaining computing time and additional information use the additional parameter -q. You will see an output similar to the example below:

> r_wlm_usage -q

Account:                               example1234
Type:                                      example
Start of Accounting Period:             08.05.2023
End of Accounting Period:               07.05.2024
State of project:                           active
--------------------------------------------------
Quota monthly (core-h):                      10000
Remaining  core-h of prev. month:             -100
Consumed   core-h current month:              1000
Consumed   core-h last 4 weeks:               8000
Consumable core-h (%):                          89
Consumable core-h:                            8900
--------------------------------------------------
Total quota (core-h):                       120000
Total consumed core-h so far:                60000
--------------------------------------------------
Default partition:                           c23ms
Allowed partitions:              c23ml,c23ms,c23mm
Max. allowed wallclocktime:             24.0 hours
Max. allowed cores per job:                     96

To view additional parameters and report settings use

r_wlm_usage -h

Sliding Window Quota

Computing time quotas are allocated on a monthly basis. However, recognizing that it may be challenging to utilize the quota precisely each month, a sliding window quota is implemented. This approach allows you to carry over unused quota from the previous month and to draw in advance from the next month's quota. Naturally, the order in which allocated computing time is consumed is as follows: first previous month, then current month, lastly next month.

Using r_wlm_usage -q shows you the sliding window quota. Consumable core-h (%) shows how much computing time is left from the previous and this month. Using more computing time will draw from the next month and will be shown a negative number.

The following table provides some examples:

Exceeding Computing Time Quotas

Exceeding your sliding window quota leads to notable changes in job processing. In such cases, further job submissions will be put on a low-priority Slurm partition, resulting in significantly longer wait times for job starts. Note that will r_wlm_usage -qwill display -101% in this situation (see fourth month in example above).

In addition, please mind the following restrictions:

• If a project's consumption exceeds six times its monthly core-h quota within a four-week period, new job submissions will be temporarily suspended until the usage drops below this threshold.
• Using more than double the total project core-h quota will permanently disablefurther job submissions for the project's period.

These restrictions apply similarly to personal compute time quotas.

Please be aware that in times of high demand, we may adjust these limits to ensure fair distribution of resources.

How to check the Billing of a Job

As stated above, one core-h typically represents the use of one CPU core for one hour. If this is not the case in your jobs then you are probably doing something wrong. After a job has started, you can check the billing using sacct:

sacct -X -j <job-id> -o AllocTRES%100

If the billing is higher than the number of CPU cores, you are paying for more than the requested cores. This can have two reasons:

1. You requested more memory than is available per core for the selected partition. If this is the case, consider switching to a partition with more memory per core.
2. When requesting GPUs, you are automatically billed for a certain number of cores, even if you did not request as many. If you need additional computing power, consider increasing the number of cores to the billing value.

See also

• Submitting a computing job with a project