Manage backends
Add or remove group backends
-
On the Groups tab, scroll to the appropriate group and click its settings icon (
). -
Click the Manage devices tab.
-
Add or remove devices.
- Add: Select backends to add to your group from the list of available backends.
- Remove: Delete a backend assigned to your group by clicking the trash icon.
-
Click Update, then close the window.
Add or remove project backends
You must add the system or simulator to the parent group before you can add it to the project.
- On the Groups page, expand the appropriate group and click the project to which you want to add a backend.
- On the project details page, select the Backends tab, then click Edit backends.
- Select a backend and optionally define the priority, maximum circuits, and maximum shots, then click Add+. See Define share and What values should I set for Max circuits and Max shots? for help setting these values. When you are done adding backends, click Update and close the window.
Configure backends
The Backends tab lists all available backends for your group or project. You can configure these values several ways:
- Define the value when adding the backend.
- Within a group: From a hub’s Groups tab, scroll to the appropriate group and click its settings icon (). On the Manage backends tab, click the edit icon by a backend, set the value, click Save, then click Update and close the window.
- Within a project: From a group’s Projects tab, scroll to the appropriate project and click its settings icon (). On the Manage backends tab, click the edit icon by a backend, set the value, click Save, then click Update and close the window.
Backend details
All backends that are allocated to the group or project are listed. Click any backend to see detailed information.
Define share
Priority of jobs in the queue is determined globally and is based on the usage of all systems (not on individual backends). Hub and group administrators can adjust the share among groups and projects from the administrator dashboard. See Fair-share queuing and What is a queue slot (share)? for more information.
A queue slot is a share in the computational capability of the fleet of IBM Quantum™ systems. A hub’s reserved capacity entitlement is proportional to the number of queue slots assigned to that hub.
Queue slots inform the fair-share algorithm to schedule submitted jobs according to a prioritization that depends on the queue slots allocated and the usage till that moment during the current rolling time window.
Your queue slot allocation determines your reserved capacity. For example, given that each system with fewer than 200 qubits is worth 20 queue slots, if your hub is allocated five queue slots, then you will be guaranteed capacity equivalent to 25% of the up-time of the average <200-qubit system, if your users maintain a continuous demand.
Note that queue slot consumption changes depending on the number of qubits. Please refer to your contract or your IBM® engagement manager for the exact metrics.
Because the fair-share algorithm balances the recent history of on-chip execution time with the order of job submissions, the length of a queue is not necessarily an indication of how long a job will take to run.
The queueing system first tries to satisfy the hub’s share. It then determines which group, and then which project, will go next. This hierarchical relationship means that while a share may be available to a hub, the queueing behavior is based on the recent activity and usage of other instances (a hub/group/project combination) 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.
Define pulse gate settings
- Maximum qubits per pulse gate - The maximum number of qubit arguments allowed to a gate. Up to three qubits are allowed (default: 3). The value set for a backend in the group settings is that backend’s default value in any project within that group.
- Maximum channels per pulse gate - The maximum number of channels you can refer to within a pulse schedule. Typically each qubit is associated with a drive channel, a measure channel, an acquisition channel, and then auxiliary control channels for things like cross-resonance. Up to nine channels are allowed (default: 9). The value set for a backend in the group settings is that backend’s default value in any project within that group.