NVMe Self-Study Bank: Keep Alive

NVMe · Q1–328

NVM Express Base 2.4NVM Command Set 1.3NVMe over PCIe Transport 1.4

Q217–Q222

Keep Alive

Optional PCIe Keep Alive detects host liveness through command-based or traffic-based timing.

Each question is followed by its explanation. Start with the volume overview, then follow the field interpretations, comparisons or processes. Essential conditions and the normal path are visible from the start. All numerical examples are hypothetical. Status is written SCT/SC; h indicates hexadecimal.

SCT
Status Code Type

Two modes with different renewal evidence

One long-outstanding command does not establish activity in every interval.

ConditionEvidence/actionInterpretation
Support/granularityKAS, TBKASKAS uses 100 ms units; mode is separate
TimeoutFID 0Fh.KATOValue may be rounded up
Command modeSuccessful Keep Alive/KATO SetRestart on qualifying success
Traffic modeCommand fetches in intervalOutstanding alone is insufficient
FID
Feature Identifier

Worked interpretation: KAS2 means 200 ms granularity; a 250 ms request is rounded upward. Schedule using actual readback.

Sources: Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4

Review the terminology when needed
Controller / namespace
A controller receives commands and manages access. A namespace is a logical storage space that commands can address. An NVM subsystem contains controllers and nonvolatile storage resources.
SQ / CQ / SQE / CQE
Submission and Completion Queues carry command entries (SQEs) and completion entries (CQEs). QID identifies a queue, CID distinguishes outstanding commands in one SQ, and NSID identifies a namespace.
Register / Identify / Feature / Log
A register exposes control or state. Identify queries capabilities and attributes; features query or configure operation; log pages report specific state or records. FID, LID, CNS and CSI select features, logs, Identify structures and command sets.
index / offset / zero-based
An index selects an entry, usually starting at 0; an offset measures distance from an origin in specified units. A zero-based count encodes count−1, but not every zero-valued field is a count. A Dword is 4 bytes; a byte is 8 bits.
Scope / reset / retention
Scope names the affected objects; retention means preserving state. Controller Reset (clearing CC.EN) is one form of Controller Level Reset, or CLR. Different CLR triggers can retain different registers.

Questions in this volume

  1. Q217 · How does a PCIe host discover Keep Alive support?
  2. Q218 · How is the timer configured, adjusted and disabled?
  3. Q219 · How does the host maintain liveness before expiry?
  4. Q220 · What cleanup is required after Keep Alive Timeout?
  5. Q221 · Must Keep Alive be reconfigured after reset?
  6. Q222 · How do command-based and traffic-based Keep Alive differ?

Q217 How does a PCIe host discover Keep Alive support?

Follow the explanation

Keep Alive monitors communication liveness, not each I/O’s execution deadline; PCIe does not require every SSD to enable it.

1. Select the target and information

Each controller has its own timer; activity on another controller does not substitute.

Nonzero KAS advertises support and 100 ms granularity units; CTRATT.TBKAS identifies Traffic Based mode.

Timer support requires the Keep Alive command; FID 0Fh KATO configures milliseconds.

FID
Feature Identifier

2. Query sequence and interpretation

Read KAS, determine mode, configure and read back the actual timeout.

PCIe defaults to disabled KATO=0; support and active use are distinct.

3. Handle missing or inconsistent evidence

KAS=0 does not promise command/feature acceptance; apply the relevant unsupported-command/feature rules.

KAS, TBKAS, command support/effects and feature behavior must agree.

First check whether an optional PCIe capability was incorrectly assumed mandatory.

Sources: Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Sources: Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Back to questions

Q218 How is the timer configured, adjusted and disabled?

Follow the explanation

The host chooses a communication interval and the controller applies supported granularity.

1. Prepare the operation

It is controller-scoped, not a subsystem-wide I/O timeout.

Read KAS, current KATO and feature saveability.

KATO is milliseconds; round upward to KAS granularity and apply an implementation minimum when needed.

2. Sequence and completion conditions

Read the effective timeout after success and update host scheduling; PCIe allows KATO=0 to disable.

With hypothetical KAS=10, 1500 ms rounds to 2000 ms unless a larger minimum applies.

3. Handle unmet conditions

An applicable transport maximum violation returns Keep Alive Timeout Invalid without changing the setting; do not invent a fixed PCIe maximum.

A larger readback can be valid because of rounding/minimums.

Sources: Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Sources: Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Back to questions

Q219 How does the host maintain liveness before expiry?

Follow the explanation

Margin accommodates scheduling and processing delay; last-moment submission does not prove timely controller processing.

1. Prepare the operation

The timer is active only with EN=RDY=1, SHN=SHST=00b and nonzero KATO.

Read effective KATO and determine the active mode.

Command Based restarts on successful Keep Alive or nonzero KATO Set, not ordinary Reads.

2. Sequence and completion conditions

The host should send at KATT/2 and keep Admin SQ space available, adjusting scheduling after successful KATO changes.

SQ
Submission Queue

Successful completions demonstrate communication, not completion of every media operation.

3. Handle unmet conditions

Missing Keep Alive completion is assessed against KATT and recovery rules rather than hidden by endless submissions.

Separate submission, controller completion and host receipt timestamps.

Sources: Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Sources: Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Back to questions

Q220 What cleanup is required after Keep Alive Timeout?

Follow the explanation

Cleanup stops processing on a failed communication path before host recovery introduces new work.

1. Identify the trigger and affected objects

PCIe cleanup neither deletes namespaces, sanitizes data nor rolls back writes.

Check CQT, CFS and Error Information with outstanding-command records.

2. State changes and recovery

Within CQT, log Keep Alive Timeout Expired, stop processing and set CFS.

Stop submissions, preserve available evidence and recover/reinitialize the path.

Cleanup establishes stopped processing, not a CQE for every outstanding command.

CQE
Completion Queue Entry

3. Verify retention and recovery

Timeout does not prove old Writes unexecuted or safely retryable unchanged.

Correlate fatal state, error record and cleanup timing separately from data effects.

First distinguish host-detected timeout from controller-detected/completed cleanup.

Sources: Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Sources: Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Back to questions

Q221 Must Keep Alive be reconfigured after reset?

Follow the explanation

Reset ends the old command environment; restored timer configuration follows feature persistence rather than host memory of old KATO.

1. Identify the trigger and affected objects

Reassess the affected controller’s configuration and activation conditions.

Read restored Current KATO and applicable Saved/Default behavior.

2. State changes and recovery

Invalid activation conditions make the timer inactive; activation initializes it to effective KATO.

Initialize, read KATO, enable/read back if needed and restart host maintenance scheduling.

Host scheduling matches the actual value, mode and new controller lifetime.

3. Verify retention and recovery

Pre-reset commands or stale CQE bytes do not establish post-reset liveness.

CQE
Completion Queue Entry

Validate restored configuration, not continuation of the old countdown to the millisecond.

Read Current before deciding whether to reconfigure; rediscovery is not universally rewriting one value.

Sources: Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Sources: Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Back to questions

Q222 How do command-based and traffic-based Keep Alive differ?

Follow the explanation

One mode relies on explicit Keep Alive commands; the other can use normal command traffic.

1. What differs

Controller TBKAS determines support; the host cannot unilaterally assume traffic-based operation.

Traffic-based controller checks for fetched commands per KATT interval; the host uses submitted-and-completed activity to decide whether to skip Keep Alive.

2. How to choose and verify

Check nonzero KAS and TBKAS; zero selects command-based behavior.

In traffic-based mode the host should check every KATT/4 and send Keep Alive when qualifying traffic is absent.

A fetch in an interval permits the next interval, so detection can take nearly 2×KATT after the last fetch.

3. Conditions that shape the comparison

Do not require expiry exactly KATT after the last fetch or treat one long outstanding command as new traffic in every interval.

Compare fetch/completion evidence and interval boundaries, not merely a prepared SQE.

SQE
Submission Queue Entry

Sources: Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Sources: Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Back to questions

Source locations and existing figure guides

Base printed page = PDF page−26; the other two use identical numbers. Locations follow the supplied PDF body and retain figure numbers. Shared pages contribute only the relevant definitions, excluding Fabrics and PCIe link/packet content.

  • Base 2.4 · §3.7.1–3.7.4
    Printed pages 120–124 · PDF 146–150
  • Base 2.4 · §3.9 (common and PCIe rules), 5.2.30.1.9
    Printed pages 129–135, 471 · PDF 155–161, 497 · Figure 481
  • Base 2.4 · §4.2.3
    Printed pages 145–155 · PDF 171–181 · Figure 101–105
  • Base 2.4 · §4.4
    Printed pages 166–169 · PDF 192–195 · Figure 126–127
  • Base 2.4 · §5.2.2
    Printed pages 183–190 · PDF 209–216 · Figure 150–156
  • Base 2.4 · §5.2.13.1.2
    Printed pages 218–220 · PDF 244–246 · Figure 212
  • Base 2.4 · §5.2.13.1.14 (header, reset, hardware, Set Feature events)
    Printed pages 244–256, 258, 262–264 · PDF 270–282, 284, 288–290 · Figure 232–244, 246, 252–253
  • Base 2.4 · §5.2.14.2.1
    Printed pages 340–387 · PDF 366–413 · Figure 338–341
  • Base 2.4 · §5.2.30.1 (common fields, scope and persistence)
    Printed pages 456–460 · PDF 482–486 · Figure 463–466
  • Base 2.4 · §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2)
    Printed pages 825–828 · PDF 851–854

When you need a field guide

Existing figure explanations have canonical locations; use these links instead of duplicating the same guide.

Original documents used
  • NVM Express Base Specification · Revision 2.4 · 2026-07-31
    NVM-Express-Base-Specification-Revision-2.4-Ratified-2026.07.31.pdf
  • NVM Express NVM Command Set Specification · Revision 1.3 · 2026-07-31
    NVM-Express-NVM-Command-Set-Specification-Revision-1.3-Ratified-2026.07.31.pdf
  • NVM Express NVMe over PCIe Transport Specification · Revision 1.4 · 2026-07-31
    NVM-Express-NVMe-over-PCIe-Transport-Specification-Revision-1.4-Ratified-2026.07.31.pdf
Jia-Chang

Jia-Chang

Human

Recent posts

PCIe Chapter 37：效能推估與跨章觀察
PCIe Chapter 37: Performance Estimation and Integrated Observation
PCIe Chapter 36：交易依賴、ID-Based Ordering 與 Message
PCIe Chapter 36: Dependencies, ID-Based Ordering, and Messages

Comments

  Write a comment ...