Fair Queue

To run quantum programs on systems and emulators users must submit execute jobs using qnexus. A nexus exeucte job targetting Quantinuum systems consists of many circuit, each mapping to a result. Circuits contain the instructions for running a program on the quantum computer, and are submitted to a user-specified emulator or device. Once the circuit has completed execution on Quantinuum systems, a result is available to view by the end user. There is no expiration date on the retention period of nexus jobs. In other words, nexus jobs are stored on database forever.

Jobs submitted to systems and emulators and devices enter a fair queue. Jobs will wait in the queue until they run on the target device. A fair queuing process is used to ensure each organization’s queue is equally represented for machine access. The jobs submitted by users in the same organization are executed in the submission order. If users submit a job to a specific machine that is not available, the jobs will remain at the top of an organization’s queue until that machine is available. Machines do not need to be online when submitting jobs. Users are encouraged to submit jobs at their convenience. The quantum computers are periodically taken down for upgrades. If a job is submitted while the machine is in an upgrade cycle, it will remain in the queue and run when the machine is back online. Users are able and encouraged to submit jobs to the queue.

The Quantinuum Nexus user portal displays all jobs submitted to the queue for a specific user. qnexus can be used to programmatically access resource visibility. The Resource Visibility in the User Portal section narrates how project-level, job-level and device-level data can be displayed. At the device-level, calendar data is available for when the systems are operational. qnexus is used to show job-level and project-level visibility in addition to quota visibility.

Queues

Nexus Queue

Nexus operates a First-In First-Out (FIFO) queue for all compilation jobs, in addition to execution jobs submitted to nexus-hosted emulators and simulators. Compilation jobs have a 5 minute window before termination and job failure. All jobs submitted to nexus for execution on Quantinuum systems are submitted to a first-in, first-out queue within nexus. All jobs submitted to nexus will be directed to Quantinuum systems in order of submission date - jobs submitted earlier will be submitted first. User and group priorities only impact job selection within the Quantinuum Fair Queue.

Fair Queue on Quantinuum Systems

The fair-share queue fairly distributes access opportunities to quantum computers and emulators across users from all organizations. The fair-share queue is an important step in the software stack for scheduling jobs and maximizing compute on the hardware.

Job Selection

Job selection with the fair-share queue is determined by Hardware Quantum Credits (HQCs) accumulation per organization, group priority within an organization, user priority within a group and submission date for all jobs of a selected user.

  1. HQCs accumulation

    • An organization from all organizations submitting to a target is selected based on the HQC accumulation, how many HQCs have been consumed by the organization, within the Fair Queue Time Window (FQTW).

    • The FQTW is defined to be 2-4 hours.

  2. Group Priority

    • Within the selected organization, jobs from User Groups are ranked and chosen according to group priority.

    • If multiple groups have the same priority, HQC accumulation is used as a secondary criterion to select jobs. Jobs will run first for groups with lower HQC accumulation.

  3. User Priority

    • Once a group is selected, the highest priority user is selected.

  4. Submission Date

    • The job with the oldest submission date of the selected user begins execution.

  5. Job Execution

    • The selected job is chunked into slices based on the number of shots requested by the user and the complexity of the job. Job complexity is determined by the number of two-qubit gates and measurement gates.

    • A slice of a job is a small number of shots that can be executed between calibration runs.

  6. Update organization HQC accumulation within FQTW.

RZZ gate

For jobs submitted with large shot counts, jobs are chunked into slices with a smaller shot counts. The number of shots in a slice is dynamically chosen by the system compiler and will vary with the complexity of the circuit.

A series of system checks are performed before and after each slice. If an error is detected, any suspect results are rejected and the failed chunk shots are rerun at no additional cost.

Once a job is selected and starts running, it is assigned a start date. Once the job finishes running, it is assigned a result date. For jobs consisting of multiple slices, the time between the start date and result date will include all of the system checks and calibrations that happened in the middle of that job and possibly slices from other jobs in the queue. Users should not expect that result date less start date be the system run-time of the job as this is more than likely not the case.

Partial results can be retrieved for the slices that have completed running on the systems or emulator using the get_partial_results method in pytket.

Jobs running on the emulator will have a runtime dependent on the number of qubits. A 17-qubit emulation may require 10 minutes to complete while a 25-qubit emulation may require over 24 hours to complete.

Fairness is dictated by the HQC accumulation for each organization. Organizations with premium subscriptions will benefit from slower HQC accumulation and therefore will receive higher priority in the fair-share queue.

Organizations

Users from the same organization submitting jobs to a system compete for access through their organization’s queue. Organizations consist of users and groups. Multiple users can be in a group and organizations can have multiple users. Organizations can choose whether or not to use user group priorities or user priorities, controlled by organization administrators. If a user has no association with an existing group, they are assigned the DEFAULT group of the organization.

  • Organization priority (default: 5) is defined between 1 (highest) and 10 (lowest).

  • Higher priority jobs run before lower priority jobs.

  • Jobs not associated with any group are assigned to the DEFAULT group with the default group priority (5).

Long queue times can arise if there are several jobs submitted from the same organization.

Organization administrators cannot modify how the Fair Queue selects organizations.

RZZ gate

Job Chunking

For jobs submitted with large shot counts, jobs are chunked into slices with a smaller shot counts. The number of shots in a slice is dynamically chosen by the system compiler and will vary with the complexity of the circuit.

A series of system checks are performed before and after each slice. If an error is detected, any suspect results are rejected and the failed chunk shots are rerun at no additional cost.

The time to solution, the difference between the result-date and the start-date, is contaminated by chunks of jobs from other organizations. It does not reflect the true execution time on the system. Batching ensures chunks of jobs from other users do not run during your jobs. Jobs in a batch will run consecutively after each other, after the batch starts.

RZZ gate

Minimize Queue Time

The fair-share queue distributes access to systems and emulators across multiple organizations. Internally within a selected organization, users can improve the likelihood of their job being selected for execution via communication with the organization administrator. The organization administrator can control user and group priorities to ensure a specific user’s jobs start running first within the organization. Group and user priorities can be set by an organization administrator using the user portal or Quantinuum API. The schedule for operations hours on the system is displayed on the user portal. Emulator targets are readily available to use 24 hours a day. Below are a list of steps a user should follow:

  1. Keep jobs in the organization queue.

  2. Utilise batching when submitting a large number of jobs.

  3. Use User and Group priorities to increase job priority within the organizational queue.

  4. Plan QPU and emulator usage around the calendar month.

  5. Plan usage around published calendar.

  6. Submit to the correct system for the job.

RZZ gate