Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Currently, the cost is based on elapsed time and the number of cores reserved (not used!) by the batch jobs. In general, most tools and applications from our Software Catalog can be used free of charge even if the program is burdened with a licence. Only in a few cases, you need to register and pay an additional fee in order to access special applications. All the information is are reported in the description of the specific application: see application-software-science.

...

ACCOUNT: indicates the grant or resource allocation which you can use for your batch jobs. Usually, a "budget" is associated with an Account and measures reports how many resources (computing hours) can be used within that Account. In UG2.2 Become a user we describe the several ways your username to can be associated with an account.

...

On some clusters (for example on GALILEO or MARCONI100) you can choose to allocate for your job only part of the node. You are not forced to allocate all of it as it happens in clusters (like MARCONI) running in exclusive mode. In this case, the accounting procedure takes also into account the amount of memory you request for your job. If you ask for an amount of memory that is larger than the equivalent number of cores requested, the jobs will be billed for a larger number of cores than the ones you have reserved.
The billing always follows the basic idea illustrated above, but a generalized parameter for the number of reserved cores, accounting for the memory request, is now used:

...

For GALILEO, every GPU will be treated as 18 cores in terms of accounting. That is because GPU nodes have 36 CPUs and 2 GPU each. So allocating 1 GPU is equivalent to allocate half of the node (i.e. 18 CPUs). For MARCONI100 that has 32 CPUs and 2 GPU each the rule holds similarly.

Some examples based on GALILEO (1 node):

  • cpus=24, gpus=1 ==> the number of GPUs requested is equal as having requested 18 CPUs, but since 24 of them have been requested in the standard way, they are not taken into account. Thus 24 CPUs will be billed;
  • cpus=6, gpu=1 ==>  the number of GPUs requested is equal as having requested 18 CPUs, which is higher than the number of CPUs requested. Thus 18 CPUs will be billed;
  • cpus=24, gpus=2 ==> the number of GPUs requested is equal as having requested 36 CPUs, while 24 of them have been requested in the standard way, and they are not enough to cover for the GPU request. Therefore 36 CPUs will be billed;
  • cpus=24, gpus=1,mem=115GB ==> the situation is similar to the first example (so 24 CPUs billed), but the memory request is higher than what is guaranteed by the simple allocation of the CPUs or GPUs, since it is equivalent of allocating the entire node. So, 36 CPUs will be billed.

Low priority production jobs for active projects

...

with exhausted budget

...

Non-expired projects with exhausted budgets may be allowed to keep using the computational resources at the cost of minimal priority. Ask superc@cineca.it to motivate your request and, in case of a positive evaluation, you will be enabled to use the qos_lowprio QOS:

...