Property specifications

Documentation » Jobs'/Nodes' property specifications

Similarly to MetaCentrum, when submitting a job to the CERIT-SC computing infrastructure (no matter whether via the CERIT-SC frontend or any of the MetaCentrum frontends) it is necessary to specify its properties and requirements:

1. basic properties of required execution nodes
   • the number of required nodes/processors, the amount of required memory, available SW licenses, or the amount of storage space on the local /scratch volume
   • in the environment of the CERIT-SC computing infrastructure, these properties are specified in the same way as in the MetaCentrum computing infrastructure - details and examples of such specifications can be found at MetaCentrum site
2. extended properties of required execution nodes
   • CPU type, operating system, network subsystem, etc.
   • since the CERIT-SC computing environment uses just the nodes with a uniform HW/SW equipment, a specification of these properties is not necessary at this time (all the nodes offer a uniform set of the following properties: debian, debian6, x86_64, infiniband, cl_zewura and nfs4). However, after the planned enlargement of the CERIT-SC computing infrastructure, and/or after providing the interoperability between the CERIT-SC and MetaCentrum schedulers, the usage of these extended properties will be necessary - we'll inform you as soon as this happens.
3. special queues requirements
   • currently available special queues are:
     • backfill - low-priority queue; jobs from this queue "fill" free gaps in the schedule (e.g., when waiting for a completion of a job, which holds resources requested by a starving job). The queue accepts just single-node jobs with the specified maximum run-time in the length up to 24 hours. When necessary (e.g., reserving resources for a long-term job), the backfill jobs may be suspended or even terminated by us at any time.
   • submitting a job requesting a special queue:
     $ qsub -q QUEUENAME ...    # submitted via CERIT-SC frontend

     $ qsub -q QUEUENAME@wagap.cerit-sc.cz ... # submitted via Meta frontend
4. maximum job run-time
   • since the logic of maximum job run-time specification went through the most considerable modifications as compared to the MetaCentrum infrastructure, it is described in detail in the following section.

Maximum job run-time specification

As compared to the MetaCentrum infrastructure, where the jobs' maximum run-time (influencing their scheduling) is implicitly specified by placing the jobs into a set of pre-defined, time-limited queues (short, normal, long, etc.), all the jobs under the CERIT-SC computing infrastructure are placed into a single (default) queue. The specification of jobs' maximum run-time is then performed via an optional walltime parameter, which allows us to better optimize the scheduling process/system, and which further leads to a better user experience (faster jobs' startup) - see motivation and implementation in the section Technical details.

Important notes:

• All the jobs exceeding their reserved time-frame, specified via the walltime parameter, will be automatically killed by the scheduling system.
• Note, that the scheduler does not restrict the users in the specification of the length of the time-frame they require for their jobs - i.e., even a really short job may be submitted with a long-term run-time specification. However, in such a case, the job will be handled as a long-term job, which may negatively influence its scheduling (in other words, the job may be started later than it would be with a more appropriate maximum run-time specification).

Hint: In generally, it can be recommended to specify the maximum job run-time in the length of 20-30 % longer than being supposed. If the supposed run-time cannot be easily estimated, we suggest you to run the first job run/iteration with a longer time-frame specification, and use the real job's run-time (available via the qstat command) as an estimation for the following job runs/iterations.