49 lines
5.3 KiB
Plaintext
49 lines
5.3 KiB
Plaintext
---
|
||
title: Fair-share scheduler
|
||
description: How the IBM Quantum fair-share scheduler determines order of jobs submitted to quantum processing units
|
||
|
||
---
|
||
|
||
# Fair-share scheduler
|
||
|
||
When you submit a job to a quantum processing unit (QPU), it enters the scheduler for the specific QPU, joining the pool of jobs (from all users) that are waiting to be executed on that QPU. The order in which these jobs are executed is, by default, determined by a fair-share formula. As discussed below, this formula attempts to balance the workload between different [instances](instances) according to the allocated QPU access amount over a given time window. In practice, this means that jobs from various instances are interweaved in such a way that the order in which jobs complete is not necessarily the order in which they were submitted. Because the order is calculated dynamically as new jobs arrive, it is generally impossible to guarantee when a job will be executed from the fair-share scheduler.
|
||
|
||
## Fair-share terms
|
||
|
||
* **Channel:** An entity providing access to quantum computing. IBM Quantum™ Platform and IBM Cloud® are channels that provide access to Qiskit Runtime services.
|
||
* **Instance:** A combination of hub/group/project.
|
||
* **Hub:** Administrative hub, which represents the top level of an organization, such as an academic, industry, or research partner.
|
||
* **Group:** A mid-level structure to which access allocation can be allocated by the hub for one or more collections of users (projects).
|
||
* **Project:** The base-level construct to which time are allocated from the overarching group, and to which users are directly assigned.
|
||
* **28-day rolling window:** The fair-share scheduler accounts for usage over a rolling time window. Only execution time accumulated within that window is accounted for the purpose of fairness. The length of that window is currently 28 days. When the fair-share scheduler is invoked, it takes into account usage starting 28 days ago.
|
||
* **Time used:** For every group and project, during the 28-day rolling window, we account for all usage on all the QPUs of the IBM Quantum Premium Plan. These include all successful jobs, as well as jobs returning known select error codes.
|
||
|
||
## Allocation and administration
|
||
|
||
IBM® assigns allocation to each hub based on their allotted capacity contracted under the Premium Plan subscription. Hub administrators then decide what portion of this allocation to assign to each of their groups. Similarly, group administrators will decide what portion of allocation to assign to each of their projects.
|
||
|
||
The hub administration user interface is used to assign allocation, in minutes, to groups. The entire hub allotted time can be distributed to the underlying groups, and the hub administrator can control the time distribution by specifying the allocation in minutes for each group.
|
||
|
||
The fair-share scheduler takes into consideration how the allotted time is distributed across groups and projects to determine job prioritization.
|
||
|
||
The scheduler combines a group’s allocation with the allotted time of its hub, to determine the total fraction of computational power allocated to that group.
|
||
|
||
For example, assume only two groups maintain jobs in one queue. With all else being equal, a group with twice the number of minutes will have twice the number jobs execute.
|
||
|
||
## How the fair-share scheduler works
|
||
|
||
The fair-share scheduler selects jobs to execute on a QPU in a dynamic order so that no instance can monopolize the QPU. When a QPU is ready for additional work, it requests the next job from the fair-share scheduler. The scheduler's default behavior is to select the next job by first identifying the group that has used the least amount of their allocation within the current scheduling window. If the selected group has more than one project, and both have jobs waiting to be executed, then the scheduler identifies the project that has used the least of their allocation within the scheduling window. Finally, if the selected project has submitted more than one job, the scheduler will select the oldest job first. Thus, within a project, the scheduler works on a first-in-first-out (FIFO) basis.
|
||
|
||
## Wait-time estimate
|
||
|
||
A wait-time estimate is provided through IBM Quantum Platform. The computed time is the result of a scheduling simulation that predicts one possible execution pattern, given the current fair-share ordering of all the jobs waiting for that QPU and the approximate runtime of each job. The dynamic nature of the fair-share scheduler means that this estimated time is not fixed and can vary, sometimes dramatically. This wait time is also subject to limitations inherent in estimating the execution time for Qiskit Runtime jobs. For these jobs, where an accurate estimation of time is not feasible, the maximum allowed runtime is used as a proxy. In practice, this means that the duration for a Qiskit Runtime job can be over-estimated by up to eight hours, the maximum allowed Qiskit Runtime job duration for Premium Plan users.
|
||
|
||
Your job’s position in the queue is listed in the **Queue position** column on the [Workloads page](https://quantum.ibm.com/workloads).
|
||
|
||
## Next steps
|
||
|
||
<Admonition type="tip" title="Recommendations">
|
||
- Try the [Grover's algorithm](https://learning.quantum.ibm.com/tutorial/grovers-algorithm) tutorial.
|
||
- Learn how to [Monitor a job](monitor-job).
|
||
</Admonition>
|