Manage your allocation
A hub administrator can distribute the allotted time of the hub in minutes across multiple groups and projects, while a group administrator can distribute their group allocation within their projects.
The time that you allocate is used by the fair-share algorithm and determines the priority in the queue, based on usage of all QPUs over a rolling time window of 28 days; read more in the Fair-share scheduler topic. Optionally you can set this time as a limit for the group or project, or protect this time to ensure that other instances with no limit can't consume it.
Groups and allocation user interface
Allocate time
To allocate time, from the hub details page, select the Groups and allocation tab and click on Edit allocation. You can then enter the group or project allocation time in minutes.
When editing the time, the relative percentage over the parent-level total allocation will be displayed next to it. The usage for the current cycle is also displayed, which can be used as a reference to configure the allocation. Click this number to display the administration analytics panel filtered by the group or project selected, providing a more detailed view of the usage distribution over time, across QPUs and collaborators for the past 28 days.
Indicators alert you to situations in which there is unassigned capacity, or a group or project has reached or exceeded their allocation.
The allocated time for your groups can't exceed the allotted time of the hub. The time allocated to the projects of a group can't exceed the group's total allocation. Unassigned capacity can still be used by groups or projects with no assigned limit. The total time allocated and time remaining are displayed at the bottom of the table for groups, or at the botton of the group row for projects in a group.
When you're done with your changes, click on Save changes.
We recommend to limit/protect groups only when more than 200 minutes are assigned, to optimize utilization of the overall hub capacity.
Set up consumption limits
By default, a group or project's allocation does not limit that group or project from consuming more time if available.
To set the allocated time as a limit, from the hub details page, select the Groups and allocation tab and click on Edit allocation, find the group or project that you want to set a limit for, and click the Set as limit box. It will change color once checked.
The limited groups or projects cannot use more time until it is available. If they have reached their limit, collaborators can submit new workloads, which will remain queued until more time is available.
Once a group or a project reaches their limit, the active workloads won't be canceled and will continue running.
Protect time
Groups or projects with no limit could potentially consume time not used by others. Setting up protected time for a group or project ensures that the allocated time is reserved and can't be consumed by others, even if is not used.
To protect the time allocated to a group or project, from the hub details page, select the Groups and allocation tab, click Edit allocation, find the group or project that you want to protect time, and click the Protect time box. When checked, the box will change color.
To protect time for a project, the group time also needs to be protected. A protected group or project, if not limited, could still consume additional unprotected time available.
Example of a hub distribution on which group A/g3 has their time protected, which prevents the unlimited group A/g1 to consume that time
If you're unable to enable Protect time for any of your groups, contact your IBM engagement manager.
Collaborators
Collaborators can see a summary of the usage of the selected premium instance in their Dashboard, including their own usage time, the total usage, and the remaining time if their instance has a limit.
An alert displays when an instance has reached its allocated time. If the instance is limited, it will indicate that the instance has exceeded its allocation; if the instance is not limited, it will indicate that workloads will run at lower priority until more time becomes available.
Usage view of a collaborator for an instance exceeding their limit
Usage view of a collaborator for an instance without limit exceeding their allocation