Skip to content

Sometime "timeout", sometimes "TTL" #3056

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Sometime "timeout", sometimes "TTL" #3056

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
96402e6
timeout and ttl
1ucian0 Apr 25, 2025
18b02e9
expire
1ucian0 Apr 25, 2025
821c6ab
small tweaks
abbycross Apr 25, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions docs/guides/execution-modes-faq.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -57,18 +57,18 @@ No. On-demand calibration is not available.

<details>
<summary>
Is there an interactive timeout (ITTL) with session mode?
Is there an interactive timeout (interactive time to live, or interactive TTL) with session mode?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When we revamped the content of execution modes, we standardized the wording to be interactive TTL and maximum TTL. Apparently we missed a few places. But they should just follow the same wording instead of using this long explanation.

Although @abbycross can we use TTL here if it's explained in a previous page, or do we still need to spell it out in the first mention?

</summary>

Yes. This reduces unwanted cost if a user forgets to close their session.
</details>

<details>
<summary>
Can I change the interactive timeout (ITTL) or the maximum timeout of a session?
Can I change the interactive timeout (interactive time to live, or interactive TTL) or the maximum timeout (time to live, or TTL) of a session?
</summary>

You cannot change the interactive timeout value. You can change the maximum timeout value of a session (see [Specify the session length](run-jobs-session#specify-length)), but it must be less than the system-defined maximum. Ask your administrator to contact IBM support if you need a different interactive TTL or system maximum TTL.
You cannot change the timeout (interactive time to live, or interactive TTL) value. You can change the maximum TTL value of a session (see [Specify the session length](run-jobs-session#specify-length)), but it must be less than the system-defined maximum. Ask your administrator to contact IBM support if you need a different interactive TTL or system maximum TTL.

</details>

Expand Down Expand Up @@ -101,7 +101,7 @@ No. Sessions run in dedicated mode, which means that the user has total access
Is compilation time counted as usage in session mode?
</summary>

Yes. In session mode, usage is the wall clock time the QPU is **committed to the session**. It starts when the first session job starts and ends when the session goes inactive, is closed, or when the last job completes, whichever happens **last**. Thus, usage continues to accumulate after a session ends if the QPU is still running a job. Additionally, time after a job completes while the QPU waits for another session job (the interactive time to live (ITTL)) counts as usage. This is why you should ensure the session is closed as soon as you are done submitting jobs to it.
Yes. In session mode, usage is the wall clock time the QPU is **committed to the session**. It starts when the first session job starts and ends when the session goes inactive, is closed, or when the last job completes, whichever happens **last**. Thus, usage continues to accumulate after a session ends if the QPU is still running a job. Additionally, time after a job completes while the QPU waits for another session job (the interactive time to live) counts as usage. This is why you should ensure the session is closed as soon as you are done submitting jobs to it.
</details>

## Batch
Expand Down
4 changes: 2 additions & 2 deletions docs/guides/run-jobs-batch.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -69,7 +69,7 @@ Default values:
| --- | --- | --- |
| Both Open and Premium Plan | 1 sec | 10 min |

To determine a batch's max TTL or interactive TTL, follow the instructions in [Determine batch details](#batch-details) and look for the `max_time`or `interactive_timeout` value, respectively.
To determine a batch's maximum TTL or interactive TTL, follow the instructions in [Determine batch details](#batch-details) and look for the `max_time`or `interactive_timeout` value, respectively.

<span id="close"></span>
## Close a batch
Expand Down Expand Up @@ -108,7 +108,7 @@ batch.close()
<span id="batch-details"></span>
## Determine batch details

For a comprehensive overview of a batch's configuration and status, including its interactive and max TTL, use the `batch.details() method`.
For a comprehensive overview of a batch's configuration and status, including its interactive and maximum TTL, use the `Batch.details` method.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know the convention in Qiskit is to use <class name>.<method name>. But there was confusion in the past where people thought that means it's a class method.


```python
from qiskit_ibm_runtime import QiskitRuntimeService, batch, SamplerV2 as Sampler
Expand Down
8 changes: 4 additions & 4 deletions docs/guides/run-jobs-session.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -82,7 +82,7 @@ with Session(backend=backend):
<span id="specify-length"></span>
## Session length

The maximum session time to live (TTL) determines how long a session can run. You can set this value with the `max_time` parameter. This should exceed the longest job's execution time.
The maximum session time to live (TTL) determines how long a session can run before it expires. You can set this value with the `max_time` parameter. This should exceed the longest job's execution time.

This timer starts when the session starts. When the value is reached, the session is closed. Any jobs that are running will finish, but jobs still queued are failed.

Expand Down Expand Up @@ -113,22 +113,22 @@ Default values:
</CloudContent>
*\* Certain Premium Plan instances might be configured to have a different value.*

To determine a session's max TTL or interactive TTL, follow the instructions in [Determine session details](#session-details) and look for the `max_time`or `interactive_timeout` value, respectively.
To determine a session's maximum TTL or interactive TTL, follow the instructions in [Determine session details](#session-details) and look for the `max_time`or `interactive_timeout` value, respectively.

<span id="ends"></span>
## End a session

A session ends in the following circumstances:

* The maximum timeout (TTL) value is reached, resulting in the cancellation of all queued jobs.
* The maximum time to live (TTL) value is reached, resulting in the cancellation of all queued jobs.
* The session is manually canceled, resulting in the cancellation of all queued jobs.
* The session is manually closed. The session stops accepting new jobs but continues to run queued jobs with priority.
* If you use Session as a context manager, that is, `with Session()`, the session is automatically closed when the context ends (the same behavior as using `session.close()`).

<span id="close"></span>
### Close a session

A session automatically closes when it exits the context manager. When the session context manager is exited, the session is put into "In progress, not accepting new jobs" status. This means that the session finishes processing all running or queued jobs until the maximum timeout value is reached. After all jobs are completed, the session is immediately closed. This allows the scheduler to run the next job without waiting for the session interactive timeout, thereby reducing the average job queuing time. You cannot submit jobs to a closed session.
A session automatically closes when it exits the context manager. When the session context manager is exited, the session is put into "In progress, not accepting new jobs" status. This means that the session finishes processing all running or queued jobs until the maximum timeout (time to live, or TTL) value is reached. After all jobs are completed, the session is immediately closed. This allows the scheduler to run the next job without waiting for the session interactive timeout, thereby reducing the average job queuing time. You cannot submit jobs to a closed session.

<CloudContent>
<Admonition type="caution">
Expand Down