Scheduling

In the HiPerGator SLURM implementation, a job’s priority and resource limits are determined by its QOS (Quality of Service):

  • Every group with a HiPerGator investment has a corresponding SLURM account;
  • Each SLURM account is associated with a high-priority investment QOS and a low-priority burst QOS;
  • QOSs available to any particular user are determined by that user’s group associations in SLURM.

Group Associations

Any user with membership in a vested group (i.e. any group with an investment and corresponding computational allocation) has a primary group association to that group’s account in SLURM. Unless otherwise specified by the user’s job, SLURM will default to using the investment QOS of the user’s primary group association.

Users with secondary membership in one or more allocation groups have a corresponding number of secondary group associations to those groups’ accounts in SLURM. Detailed instructions for specifying the use of a certain SLURM account and/or QOS can be found on our wiki.

For more information regarding allocations and group membership, view the Groups and Allocations policy page.

Our Commitment: Quality of Service

These procedures are in place to ensure that investors have high quality access to the resources in which they have invested and on which they rely for their research. We invite and encourage feedback from investors and non-investors alike. It is our intent to be as flexible and helpful as possible to all users of our facilities. As an investor, if we are not meeting your needs, please contact the Research Computing director, staff, or the Chair of the Research Computing Advisory Committee as soon as possible so that we may address the issue.

Service Level Agreement

We commit that investors get access to their NCUs (compute cores) and NGUs (GPUs) in their investment within a few SLURM scheduler cycles (each schedule cycle is 90 seconds).