Fair-share queuing system: frequently asked questions (FAQ)¶

A hub’s entitlement determines its proportional share of a system, which is measured in portions of system shares. System shares implement a fair-share algorithm that helps to facilitate job prioritization. The algorithm balances the recent history of on-chip execution time with the order of job submissions, in order to determine which jobs run next, and where in the queue a submitted job will sit. Therefore, the length of a queue is not necessarily an indication of how long a job will take to run.

The queuing system first tries to satisfy the group’s share. It then determines which project will go next. This hierarchical relationship means that while a system share may be available to a group, the queuing behavior is based on the recent activity and usage of other hub/group/project combinations in the hub.

Example:

User A in one hub, who has not submitted a job for a long time, submits a job to a queue. User B, in a different hub, is constantly submitting jobs to the same queue. Even though User A’s job may have been submitted after User B’s jobs, User A’s job may be interleaved among User B’s jobs already in the queue, or User A’s job may be run before all of User B’s submitted jobs.

Your contracted system share will not be guaranteed on a single system. The new dashboard should help you track your members’ usage, and optimize systems and share balance to hit your targets. Usage is throughout a rolling window, and thus we cannot also guarantee that you can reach your system share over a shorter span of time.

Jobs can be part of a dedicated system reservation, part of an active session, or neither. For each backend, jobs that are part of a reservation take priority. If there are no jobs from a reservation, jobs that are part of an active session are run. If there are no jobs in an active session, the next job from the regular fair-share queue is run.