Cookies on this website

We use cookies to ensure that we give you the best experience on our website. If you click 'Accept all cookies' we'll assume that you are happy to receive all cookies and you won't see this message again. If you click 'Reject all non-essential cookies' only necessary cookies providing core functionality such as security, network management, and accessibility will be enabled. Click 'Find out more' for information on how to change your cookie settings.

How the scheduler manages fair share of resources amongst all users

To prevent a single user from using all available resources on the cluster we have a range of 'Quality of Service' rules that are enforced. The current rules came into force on the 14/3/2025 and are detailed below:

Partition QOS Limits across partition
short
    • 4 Jobs
    • 10 CPUs (threads)
    • 256GB of memory
    long
    • 2 Jobs
    • 10 CPUs (threads)
    • 256GB of memory
    gpu_short
    • 2 jobs
    • 10 CPUs (threads)
    • 128GB of memory
    • minimum of 1 GPU
    • maximum of 4 GPUs
    gpu_long
    • 2 jobs
    • 10 CPUs (threads)
    • 128GB of memory
    • 1 GPU
    Interactive Jobs
    • 1 of each of Desktop,
      MATLAB, Jupyter and RStudio
    • 8 CPUs (threads) (minimum of 2)
    • 256 GB of memory

    At the discretion of IT staff some of these rules can be relaxed on a per-job basis, but where this is done, these jobs will be restricted to one at a time.

    Your job's position in the queue depends on several factors:

    • How many jobs you have run in the last three days
    • The CPU threads, memory and GPUs you have requested, in the ratio 1:2:1
    • How long you have been waiting for

    Interactive jobs have a different usage history to queued jobs, and so submitting lots of jobs or running interactive sessions for long periods/regularly will not effect your priority for jobs of the alternate type.