NVMe Base 2.4: Telemetry: capture and consistent retrieval
00.01.Telemetry exposes collected internal state as host-readable logs. The goal is a complete, consistent capture: who creates it, how large each area is, and whether it changes during segmented retrieval.
- Host
- The system running the operating system and issuing NVMe commands.
The main ideas
Establish who created the capture
01-01Host-initiated and controller-initiated logs have different creation and acknowledgment rules.
- controller
- Controller, the entity that implements the NVMe interface, fetches commands, and reports completions.
Use the header to find the data
02-01Read the header and area boundaries to plan retrieval. Standardized locations and vendor-specific payload formats answer different questions.
Keep segmented reads consistent
03-01Check capture identity and change information so that multiple reads do not combine data from different captures.
Connecting the main ideas
00.02.Distinguish host-initiated and controller-initiated logs, then use the header to establish area boundaries. Preserve capture identity across reads and acknowledge retrieval according to that log’s rules. Standardized locations do not define the contents of vendor-specific payloads.
01 Computing snapshots from Last Block
01.01.Areas are differently sized views starting at the same block 1. Read the fields the header, select the final applicable populated area, and do not add the three Last Block numbers.
01.02.Telemetry uses block 0 for its header and 512-byte blocks. Every Data Area begins at block 1. Areas 2/3/4 are larger cumulative sets, not disjoint regions placed after Area 1. Last Block is an inclusive block number; payload format and size are vendor-defined.
Sources: Base 2.4 §8.1.30; 5.2.13.1.8-5.2.13.1.9
Source: NVME-BASE-2.4, Rev. 2.4, §8.1.30; 5.2.13.1.8-5.2.13.1.9, printed pages 232-237,733-737, PDF pages 258-263,759-763
| Data area | Included blocks | Last Block constraints |
|---|---|---|
| Area 1 | 1 through L1 | L1=0 means no data |
| Area 2 | 1 through L2 | L2 >= L1 |
| Area 3 | 1 through L3 | L3 >= L2 |
| Area 4 | 1 through L4 | Check support separately |
02 Snapshot creation, chunked reads, and acknowledgement
02.01.Separate creating 07h data from subsequent reads; the controller decides 08h capture timing. For both, verify generation and distinguish event acknowledgement from payload deletion.
- Read the header and save its generation number.
- Read the data in segments from the same snapshot.
- Read the header again and compare generation numbers.
- Treat the segments as one snapshot only when the generations match.
02.02.CTHID for LID 07h is CDW10 bit 8: one requests a new capture and zero does not update that snapshot. MCDA occupies bits 11:9 and applies only when MCDAS=1 and CTHID=1; 001b through 100b request creation through Areas 1 through 4, while 000b lets the controller decide. MCDAS comes from the LID Specific Parameter in Supported Log Pages.
- CTHID
- Create Telemetry Host-Initiated Data; the 07h capture request, cleared for subsequent reads of that snapshot.
- MCDAS
- Maximum Created Data Area Supported; bit 0 of the 07h LID Specific Parameter, advertising MCDA support.
- MCDA
- Maximum Created Data Area; selects the largest area to create when supported and capture is requested.
- CDW
- CDW (Command Dword): a 32-bit command field. In CDW10, 10 is the field index, not a byte offset.
- LID
- Log Page Identifier: selects the type of log page to read.
Sources: Base 2.4 §5.2.13.1.8
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.8, printed pages 232-235, PDF pages 258-261
| Snapshot-control field | Action or report | Consideration during chunked reads |
|---|---|---|
| CTHID=1 | Triggers a new 07h capture | Do not create again for subsequent chunks |
| MCDA | Limits the areas created | Check MCDAS first |
| RAE=1 | Retains the event | Does not exclude another reader |
| TCDA=0 | No update since acknowledgement | In 2.4 it does not mean payload disappearance |
- TCDA
- Telemetry Controller-Initiated Data Available; in 2.4, indicates an update since the last RAE=0 acknowledgement.
- RAE
- Retain Asynchronous Event; use one during Telemetry collection and zero to acknowledge completion.
Where to continue in the specification
03.01.Use the flow above to frame the problem, then open the corresponding sections for fields and full conditions. The Chinese tutorial also explains every in-scope figure with its takeaway, example, and details.
| Concept to explain | Specification sections |
|---|---|
| Computing snapshots from Last Block | Base 2.4 §8.1.30; 5.2.13.1.8-5.2.13.1.9 · Base 2.4 §8.1.30; 5.2.30.1.15 · Base 2.4 §5.2.13.1.8-5.2.13.1.9 |
| Snapshot creation, chunked reads, and acknowledgement | Base 2.4 §5.2.13.1.8 · Base 2.4 §8.1.30 · Base 2.4 §5.2.13.1.9 · Base 2.4 §5.2.13.1.8-5.2.13.1.9 · Base 2.4 §8.1.30; 5.2.30.1.6 |
Check your understanding
1. If Area 1 Last Block is 3 and Area 2 Last Block is 7, which payload blocks belong to Area 2?
04.01.Area 2 contains blocks 1 through 7, totaling 7×512=3584 bytes, including Area 1 blocks 1 through 3. The header is block 0 and occupies another 512 bytes. Last Block is inclusive.
Sources
Source: NVME-BASE-2.4, Rev. 2.4, §8.1.30; 5.2.13.1.8-5.2.13.1.9, printed pages 232-237,733-737, PDF pages 258-263,759-763
2. Why reread the Telemetry header after collecting its data in chunks?
04.02.A new snapshot generation may appear during collection. Rereading generation checks that the chunks still belong together; a change requires recollection. For controller-initiated data, also check TCDA to account for acknowledgement by another reader.
Sources
Source: NVME-BASE-2.4, Rev. 2.4, §8.1.30, printed pages 734-735, PDF pages 760-761
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.9, printed pages 237, PDF pages 263


Comments