About Job Priorities

The NeSI Access Policy prescribes default priorities for jobs running on the NeSI Platforms. These are:

Table 1: Base Job priorities on NeSI Platforms (both Maui and Mahuika)

Base Priority

Project Class



Highest Priority



This ensures that whichever partition your job runs in, it will get the highest base priority

High Priority

Institution, Subscriber


Use this QoS if your job is accessing institutional resources, i.e. Collaborator or Subscriber

Low Priority

Proposal Development


Use this QoS if your job is a proposal development project

Lowest Priority



Use this QoS if your job is part of a Post Graduate project.

The base priorities in the table do not mean that the highest priority jobs will run first, but they do determine the rate at which jobs move through the job queues.  The order in which any job will run in a partition is based on its run-time priority, which is determined by the fair-share score of the project and whether it can run as backfill or not. The base priority is modulated by the following factors:

  • Job priority decreases as the Project accumulates core-hours over the last n days, across all partitions. This "fair share" policy means that Projects that have run many/larger jobs in the near-past will have a lower priority, and Projects with little recent activity will see their waiting jobs start sooner. We do NOT have a strict "first-in-first-out" queue policy.
  • Job priority increases with job wait time in the partition (unless the Project has exhausted its core-h allocation, in which case this does not apply). After the history-based user priority calculation in 1), the next most important factor for each job's priority is the amount of time that each job has already waited in the partition. For all the jobs belonging to a Project, these jobs will most closely follow a "first-in-first-out" policy.
  • Within any “partition”, job priority increases with job size, in cores. This least important factor slightly favours larger jobs, as a means of somewhat countering the inherently longer wait time necessary for allocating more cores to a single job.
  • Where a job can run in backfill, without holding up any higher priority job, it will run immediately.
  • All projects have the same priority in the debug partition and are scheduled on a first-in, first-out basis.



Was this article helpful?
0 out of 0 found this helpful