NVMe scenarios and source figures: lookup routes, field reasoning, worked answers and precise specification locations.
read more
NVMe Figures and Scenarios 06 · Health, Events, and Diagnostic Logs
NVM Express Base 2.4NVM Command Set 1.3NVMe over PCIe Transport 1.4
LOOKUP · FIELD INTERPRETATION · SOURCE LOCATIONS
NVMe Figures and Scenarios 06 · Health, Events, and Diagnostic Logs
Validate retrieval parameters and support, then distinguish current state, cumulative counters and historical snapshots. Telemetry and persistent-event versions, lengths and retrieval lifecycles determine whether records can be combined.
Follow a worked scenario through the specification
The returned data below are hypothetical. Start with the need and assumptions, follow the reading route to the relevant fields, then work through the interpretation. Explanations are visible; detailed sources can be expanded.
EXERCISE 01Does 120% Percentage Used mean the drive has failed?
A health report shows only a red “120%.” Separate the conclusions that SMART actually supports.
Hypothetical observations and assumptions
- LID=02h: Percentage Used=120; Available Spare=9; Available Spare Threshold=10; the spare critical-warning bit is one.
- Composite Temperature=300 K; no recent I/O success/failure trace is provided.
Which figures connect this scenario?
This is a specification reading route. The scenario separately explains action order and wait conditions.
- Identify each reported quantity
Locate Percentage Used, Available Spare and its threshold in SMART/Health and read their individual definitions and units.
Base 2.4 · Figure 213 - Correlate warnings with values
Correlate the spare critical-warning bit with Available Spare and its threshold in the same table.
Base 2.4 · Figure 213 - Explain the observations separately
Report temperature, endurance estimate and spare warnings separately, adding observed I/O behavior when that is the question.
Base 2.4 · Figure 213
Follow the field interpretation
Lookup sequence: Get Log Page LID=02h for SMART/Health; retain the warning bitmap and individual measurements instead of combining them into one health score.
Step 1Percentage Used estimates endurance consumption and may exceed 100. A value of 120 is not 120% damaged and does not alone establish inability to read or write.
Step 2Available Spare=9 is below threshold 10 with the corresponding warning asserted. That is a directly supported spare warning. Temperature 300 K is about 26.85°C, a different measurement that cannot be added to percentages.
Step 3Report endurance estimate, current warnings and recent error/I/O behavior separately. Continued service decisions also need system requirements and observed behavior; the log does not supply one universal decision score.
Detailed source locations
- Base 2.4 · §5.2.13.1.3 · Figure 213 · SMART / Health Information Log Page · Printed pages 221–225 · PDF 247–251
Continue with the other scenarios
EXERCISE 02How much data does a four-unit DUW increase represent?
Monitoring multiplies a SMART Data Units Written delta by 512 and reports a tiny workload. What is missing?
Hypothetical observations and assumptions
- DUW for the same target changes from 1000 to 1004; counters are valid, without reset or saturation; samples are 60 seconds apart.
- Host Write Commands rises by 80; no complete list of command lengths is available.
Follow the field interpretation
Lookup sequence: Take two LID=02h samples, retaining NSID, timestamps, DUW and Host Write Commands.
- NSID
- Namespace Identifier
Step 1DUW reports thousands of 512-byte units, rounded up. A delta of four corresponds to roughly 4×1000×512=2048000 bytes, not 2048 bytes.
Step 2Both endpoints are rounded, so this is not the exact payload byte count for those 60 seconds. Dividing by 80 yields only an approximate average, not proof that all Writes had the same size.
Step 3For one command’s length, use its NLB and active LBA format; cumulative deltas serve longer-term trends. Host-written data also must not be equated directly with physical NAND writes.
- LBA
- Logical Block Address
Detailed source locations
- Base 2.4 · §5.2.13.1.3 · Figure 213 · SMART / Health Information Log Page · Printed pages 221–225 · PDF 247–251
- NVM Command Set 1.3 · §3.3.4 · Figure 54 · Read – Command Dword 12 · Printed pages 49 · PDF 49
- NVM Command Set 1.3 · §4.1.5.1 · Figure 125 · LBA Format Data Structure, NVM Command Set Specific · Printed pages 94 · PDF 94
EXERCISE 03Does specifying an NSID guarantee per-namespace SMART?
- NSID
- Namespace Identifier
A report copies one SMART page to every namespace and labels each as individual usage. Does capability data support that?
Hypothetical observations and assumptions
- Identify Controller LPA reports no per-namespace SMART/Health support.
- The current LID=02h sample uses NSID=FFFFFFFFh; the controller has four active namespaces.
Follow the field interpretation
Lookup sequence: Identify CNS=01h for LPA; select NSID according to SMART rules. A report label cannot create a granularity the capability does not provide.
Step 1This is not four independent per-namespace measurements. Label the FFFFFFFFh report by its aggregate scope; copying and summing it would count the same measurement four times.
Step 2A specific-NSID request requires per-namespace SMART support and the log’s namespace rules. The existence of an NSID field in Get Log Page does not grant every LID arbitrary reporting granularity.
Step 3For Endurance Group granularity, inspect namespace ENDGID and LID=09h. Those remain group statistics, not automatically individual namespace or filesystem measurements.
Detailed source locations
- Base 2.4 · §5.2.14.2.1 · Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent · Printed pages 355–356 · PDF 381–382
- Base 2.4 · §5.2.13.1.3 · Figure 213 · SMART / Health Information Log Page · Printed pages 221–225 · PDF 247–251
- Base 2.4 · §5.2.13.1.10 · Figure 225 · Endurance Group Information Log Page · Printed pages 238–239 · PDF 264–265
EXERCISE 04Do two namespace alerts describe one shared group?
Management issues endurance alerts for NSID=2 and NSID=9. How can you determine whether they duplicate one group-level condition?
Hypothetical observations and assumptions
- Both namespaces identify ENDGID=3; LID=09h with LSI=3 has a nonzero Critical Warning.
- No result is available for group 4, and no inventory change is observed during the interval.
Follow the field interpretation
Lookup sequence: Identify CNS=00h for each NSID → ENDGID → Get Log Page LID=09h with LSI=ENDGID.
Step 1Both namespaces map to group 3. One group condition can affect how both namespaces are presented, but it remains one group-level source. Retain the mapping rather than counting two independent group failures.
Step 2For this LID, LSI selects the Endurance Group, not an NSID or high transfer-length bits. Substituting NSID=9 into LSI would select another target rather than answer the group-3 question.
Step 3A warning in group 3 does not establish a warning in every group. To compare group 4, verify its existence and obtain corresponding measurements from the same interval.
Detailed source locations
- Base 2.4 · §5.2.13.1.10 · Figure 225 · Endurance Group Information Log Page · Printed pages 238–239 · PDF 264–265
- Base 2.4 · §5.2.13 · Figure 205 · Get Log Page – Command Dword 11 · Printed pages 214 · PDF 240
- NVM Command Set 1.3 · §4.1.5.1 · Figure 123 · Identify – Identify Namespace Data Structure, NVM Command Set · Printed pages 90–93 · PDF 90–93
EXERCISE 05Does FLBA=0 identify a failed LBA when self-test is idle?
- LBA
- Logical Block Address
A tool reports both “test stuck at 45%” and “LBA 0 failed.” Find the two validity errors.
Hypothetical observations and assumptions
- LID=06h: current DSTOS=0, with percentage bytes containing 45; newest result DSTR=2.
- The latest result has VDINFO.FVLD=0 and all-zero raw FLBA bytes.
Follow the field interpretation
Lookup sequence: Get Log Page LID=06h; read current operation, then newest-result DSTR and VDINFO, and only then interpret diagnostic fields.
Step 1DSTOS=0 means no self-test is in progress, so ignore the percentage field. It is not a valid stalled 45% progress measurement from which to calculate a stall duration.
Step 2DSTR=2 identifies termination by Controller Level Reset, distinct from a test detecting media failure. Report the termination reason rather than collapsing every nonzero result into a detected media defect.
Step 3FVLD=0 makes FLBA invalid. Zero is merely raw content in an invalid field, not evidence of failed LBA zero. Apply the respective validity bits to NSID, SCT and SC as well.
- SCT
- Status Code Type
Detailed source locations
- Base 2.4 · §5.2.13.1.7 · Figure 218 · Device Self-test Log Page · Printed pages 230 · PDF 256
- Base 2.4 · §5.2.13.1.7 · Figure 219 · Self-test Result Data Structure · Printed pages 231–232 · PDF 257–258
EXERCISE 06Can Telemetry chunks from different generations be combined?
You collect controller-initiated Telemetry in chunks and then notice different headers. Is the combined file one coherent capture?
Hypothetical observations and assumptions
- Initial LID=08h header: TCDGN=10, TCDA=1, DA1LB=3; final reread: TCDGN=11, TCDA=1.
- Data is read in chunks between the headers; there is no complete record assigning each chunk to a generation.
Follow the field interpretation
Lookup sequence: Get Log Page LID=08h, retaining RAE, headers and each offset; compare TCDGN, TCDA and Data Area boundaries.
Step 1The generation change prevents claiming these chunks as one coherent capture. Mark consistency as unverified and reacquire through the log’s capture/acknowledgment process rather than merely replacing the file header.
Step 2DA1LB=3 places the Area 1 endpoint at block three; block zero is the 512-byte header. Header plus Area 1 therefore spans 4×512=2048 bytes. Correct length does not resolve generation inconsistency.
Step 3TCDA concerns update acknowledgment, not payload decoding. Even a coherent capture can contain vendor-defined internals; a common header does not define every vendor byte.
Detailed source locations
- Base 2.4 · §5.2.13.1.9 · Figure 223 · Telemetry Controller-Initiated Log Page · Printed pages 236–237 · PDF 262–263
- Base 2.4 · §5.2.13 · Figure 204 · Get Log Page – Command Dword 10 · Printed pages 213 · PDF 239
- Base 2.4 · §5.2.13 · Figure 208 · Get Log Page – Command Dword 14 · Printed pages 214–215 · PDF 240–241
EXERCISE 07Where does the next Persistent Event Log record begin?
A parser loses alignment after its first record and gets Command Sequence Error when establishing context again. Inspect lifecycle and length separately.
Hypothetical observations and assumptions
- ACT=3 succeeds with header RCE=0; the context has not been released. First record: offset=512, EHL=21, EL=28, VSIL=8.
- The header’s total length accommodates this record; ET/ETR identify a supported format.
Follow the field interpretation
Lookup sequence: Get Log Page LID=0Dh with ACT-controlled context; after the header, use ACT=0 on the same report and traverse event headers.
Step 1For ACT=3, RCE=0 means no reporting context existed before processing, not that none exists after success. A subsequent ACT=1 establishment conflicts with that context; subsequent reads should use it.
Step 2The common header is EHL+3=24 bytes. EL=28 already includes VSIL=8, leaving 20 bytes of Event Data. The next record begins at 512+24+28=564; do not add VSIL again.
Step 3For each record, check bounds against TLL and whether ET/ETR can be decoded before continuing. Release the context when finished. A complete report does not imply that every event in system history was retained.
Detailed source locations
- Base 2.4 · §5.2.13.1.14 · Figure 232 · Persistent Event Log Specific Parameter Field · Printed pages 246 · PDF 272
- Base 2.4 · §5.2.13.1.14 · Figure 233 · Persistent Event Log Page · Printed pages 247–249 · PDF 273–275
- Base 2.4 · §5.2.13.1.14 · Figure 234 · Persistent Event Format · Printed pages 249–250 · PDF 275–276
01Get Log Page – Command Dword 10
Base 2.4 · Figure 204 · Get Log Page – Command Dword 10
§5.2.13 · Printed pages 213 · PDF 239
01.1 · UseA log read may also acknowledge an asynchronous event. Preserve LID, LSP and RAE, not just buffer length.
01.2 · Fields and relationshipsLID bits 7:0 selects the log, LSP bits 14:8 is log-specific, RAE bit 15 retains the event, and NUMDL bits 31:16 supplies the low 16 bits of the minus-one Dword count combined with NUMDU. RAE=0 normally acknowledges the corresponding event on success rather than deleting all log contents.
01.3 · Interpretation and exampleAn ordinary 512-byte read needs 128 Dwords, so NUMD=127. A failed read does not acknowledge the event. Log-specific action or length rules, such as PEL ACT=3, override the general case.
Back to this volume’s figure index02Get Log Page – Command Dword 11
Base 2.4 · Figure 205 · Get Log Page – Command Dword 11
§5.2.13 · Printed pages 214 · PDF 240
02.1 · UseInspect CDW11 for large reads or resource selection. Its upper LSI half is not an extension of NUMD.
02.2 · Fields and relationshipsNUMDU bits 15:0 combines with CDW10.NUMDL into a 32-bit minus-one Dword count. LSI bits 31:16 is a log-specific identifier. Ordinary transfer size is 4×(((NUMDU<<16)|NUMDL)+1) bytes.
02.3 · Interpretation and exampleNUMDU=1/NUMDL=0 means 262148 bytes, not 65536. For LID=09h, LSI identifies an Endurance Group and must not be included in length arithmetic.
Back to this volume’s figure index03Get Log Page – Command Dword 14
Base 2.4 · Figure 208 · Get Log Page – Command Dword 14
§5.2.13 · Printed pages 214–215 · PDF 240–241
03.1 · UseCheck OT when chunked reads start at the wrong location. The same LPO can count bytes or data structures: byte offset and index offset are different units.
03.2 · Fields and relationshipsOT bit 23, when clear, interprets CDW12/13.LPO as bytes; OT=1 interprets it as a supported list index. CSI bits 31:24 chooses the applicable command set, while UIDX bits 6:0 selects a UUID index, each subject to its own conditions.
- CSI
- Command Set Identifier
03.3 · Interpretation and exampleFor an index-capable log, LPO=2/OT=1 means index 2. OT=0 instead means byte 2 and must also satisfy applicable alignment requirements. Those values are not interchangeable.
- CSI
- Command Set Identifier
04LID Supported and Effects Data Structure
Base 2.4 · Figure 211 · LID Supported and Effects Data Structure
§5.2.13.1.1 · Printed pages 217–218 · PDF 243–244
04.1 · UseInspect the descriptor for a LID before issuing special actions or index-offset reads. A standardized LID is not proof of device support.
04.2 · Fields and relationshipsLSUPP bit 0 advertises support, IOS bit 1 index-offset support, and LIDSP bits 31:16 log-specific capabilities. Ignore other fields when LSUPP is clear. IOS also depends on extended-data support.
04.3 · Interpretation and exampleLSUPP=1 with IOS=0 supports the log but not OT=1. PEL additionally uses LIDSP for extended context/header capabilities; LIDSP does not have one universal meaning across logs.
Back to this volume’s figure index05Error Information Log Entry Data Structure
Base 2.4 · Figure 212 · Error Information Log Entry Data Structure
§5.2.13.1.2 · Printed pages 218–220 · PDF 244–246
05.1 · UseRead these 64-byte entries when CQE.M or an error event calls for more detail. Newer errors appear first; each entry can identify a command, status and parameter location.
- CQE
- Completion Queue Entry
05.2 · Fields and relationshipsECNT bytes 7:0 is the error sequence number, with zero denoting an invalid entry. SQID bytes 9:8/CID bytes 11:10 identifies the command; STS bytes 13:12 records status. Parameter Error Location 15:14 contains BYTLOC within the SQE and BITLOC within that byte. NSID, CSI, OPC, CSINFO and LPVER further qualify interpretation.
- SQID
- Submission Queue Identifier
- CID
- Command Identifier, unique among outstanding commands in one SQ
- SQE
- Submission Queue Entry
05.3 · Interpretation and exampleBYTLOC=40/BITLOC=3 means SQE byte 40 bit 3, or CDW10 bit 3, not Dword 40. Non-command-specific errors can use FFFFh SQID/CID. Here PEL means Parameter Error Location, distinct from Persistent Event Log.
- SQE
- Submission Queue Entry
- SQID
- Submission Queue Identifier
- CID
- Command Identifier, unique among outstanding commands in one SQ
06SMART / Health Information Log Page
Base 2.4 · Figure 213 · SMART / Health Information Log Page
§5.2.13.1.3 · Printed pages 221–225 · PDF 247–251
06.1 · UseSMART combines current warnings, lifetime counters and durations with different units. Classify a field before comparing snapshots.
06.2 · Fields and relationshipsCW is a warning bitmap, CTEMP Kelvin and PUSED estimated lifetime percentage. DUR/DUW round up in 1000×512-byte units; zero means unreported. HRC/HWC counts commands, CBT minutes, POH hours and thermal-management totals seconds. A zero sensor is unimplemented.
06.3 · Interpretation and exampleA DUR increment of one need not equal exactly 512000 newly transferred bytes because the counter is rounded. PUSED above 100 also does not by itself establish device failure; correlate warnings, media errors and behavior.
Back to this volume’s figure index07Commands Supported and Effects Data Structure
Base 2.4 · Figure 217 · Commands Supported and Effects Data Structure
§5.2.13.1.6 · Printed pages 228–229 · PDF 254–255
07.1 · UseConsult this descriptor before an operation that may change data, namespace inventory or controller capabilities. It describes potential effects and coordination guidance, not a historical result.
07.2 · Fields and relationshipsCSUPP bit 0 reports support; LBCC bit 1, NCC bit 2, NIC bit 3 and CCC bit 4 indicate possible changes to data, one namespace’s capabilities, inventory and controller capabilities. CSE bits 18:16 and CSER bits 15:14 give submission/execution guidance; CSP bits 31:20 gives potential scope.
07.3 · Interpretation and exampleNIC=1 suggests rediscovering namespace inventory after the operation, not that one namespace was definitely added. Hosts understanding a nonzero CSER use its newer guidance rather than indiscriminately combining it with CSE.
Back to this volume’s figure index08Telemetry Host-Initiated Log Page
Base 2.4 · Figure 221 · Telemetry Host-Initiated Log Page
§5.2.13.1.8 · Printed pages 234–235 · PDF 260–261
08.1 · UseUse this header to determine host-initiated telemetry boundaries and generation. Vendor-defined payloads sit inside a commonly interpretable envelope.
08.2 · Fields and relationshipsThe first 512 bytes form the header. Data Area 1/2/3/4 Last Block fields identify final 512-byte block indices; data starts at block 1 and areas are cumulative. THS is byte 380, THDGN is byte 381; bytes 382/383 copy controller-telemetry availability/generation.
08.3 · Interpretation and exampleDA1LB=2 and DA2LB=5 mean blocks 1–2 and 1–5, not two blocks followed by five more. Preserve generation and capture actions across chunked retrieval to avoid combining different captures.
Back to this volume’s figure index09Telemetry Controller-Initiated Log Page
Base 2.4 · Figure 223 · Telemetry Controller-Initiated Log Page
§5.2.13.1.9 · Printed pages 236–237 · PDF 262–263
09.1 · UseThis header describes controller-captured telemetry scope, unacknowledged updates and generation. Notification state is not payload length.
09.2 · Fields and relationshipsTCS is byte 381, TCDA byte 382 and TCDGN byte 383; area last-block fields still describe cumulative extents. In Base 2.4, TCDA tracks updates since a successful RAE=0 acknowledgement, while TCDGN tracks captures.
09.3 · Interpretation and exampleTCDA=0 can mean a previous update was acknowledged; it does not establish absence of saved telemetry. Byte 381 in LID=07h is THDGN, so decoding it as this header’s TCS is also incorrect.
Back to this volume’s figure index10Endurance Group Information Log Page
Base 2.4 · Figure 225 · Endurance Group Information Log Page
§5.2.13.1.10 · Printed pages 238–239 · PDF 264–265
10.1 · UseUse LID=09h when aggregate SMART cannot answer health questions for each Endurance Group. Select the group through LSI before comparing reports.
10.2 · Fields and relationshipsFields include Critical Warning, Available Spare/Threshold, Percentage Used, data/media-write counters, errors and capacity. Units differ by field. Namespace Identify provides its ENDGID.
10.3 · Interpretation and exampleA warning for group 1 does not mean group 2 has the same warning. Fix ENDGID and observation time when comparing logs. Acknowledging a notification does not repair the underlying condition.
Back to this volume’s figure index11Persistent Event Log Specific Parameter Field
Base 2.4 · Figure 232 · Persistent Event Log Specific Parameter Field
§5.2.13.1.14 · Printed pages 246 · PDF 272
11.1 · UseACT manages a reporting context: the fixed event set used for a multipart Persistent Event Log retrieval. It does not select an event type.
11.2 · Fields and relationshipsACT=0 reads an existing context, 1 establishes and reads, 2 releases, and 3 establishes if needed or reuses it and reads the header. ACT=1 fails if a context exists. ACT=3 returns the 512-byte header at offset 0 regardless of ordinary NUMD/LPO settings, requiring an adequate buffer.
11.3 · Interpretation and exampleRCE=0 after successful ACT=3 means no context existed before processing, not creation failure. Continue with ACT=0; issuing ACT=1 can instead produce Command Sequence Error.
Back to this volume’s figure index12Persistent Event Log Page
Base 2.4 · Figure 233 · Persistent Event Log Page
§5.2.13.1.14 · Printed pages 247–249 · PDF 273–275
12.1 · UseRead total length and version before walking persistent events. Log revision, generation and individual event revision are distinct fields.
12.2 · Fields and relationshipsTNEV bytes 7:4 counts events, TLL bytes 15:8 counts total bytes, LREV byte 16 gives revision and LHL bytes 19:18 plus 20 gives header size. GNUM bytes 373:372 tracks newly established reports with changed content; RCI includes RCE. SEB bytes 511:480 describes supported event types, not present events.
12.3 · Interpretation and exampleLHL=492 gives a 512-byte header even when TNEV=0. Correlate context and GNUM across chunks; equal generation is not an indefinite guarantee across resets.
Back to this volume’s figure index13Persistent Event Format
Base 2.4 · Figure 234 · Persistent Event Format
§5.2.13.1.14 · Printed pages 249–250 · PDF 275–276
13.1 · UsePersistent events are variable length. Use this table to establish record boundaries before type-specific decoding rather than using a fixed stride.
13.2 · Fields and relationshipsET at byte 0 selects the event type; ETR at byte 1 selects the payload revision. The value in EHL at byte 2, plus 3, gives the common-header size. VSIL bytes 21:20 counts vendor information; EL bytes 23:22 includes both VSI and Event Data. Next=start+EHL+3+EL; ED length=EL−VSIL.
13.3 · Interpretation and exampleAt start 512 with EHL=21, VSIL=4 and EL=20, the header is 24 bytes, ED=16 bytes and next record starts at 556. Adding VSIL again incorrectly reaches 560. Do not independently pad each record to four bytes.
Back to this volume’s figure index14Persistent Event Log Event Types
Base 2.4 · Figure 236 · Persistent Event Log Event Types
§5.2.13.1.14.2 · Printed pages 251 · PDF 277
14.1 · UseAfter decoding the common header, route ET to the payload format here. The table also gives revisions and logging requirements.
14.2 · Fields and relationshipsCommon types include 01h health, 02h firmware, 04h reset, 05h hardware, 06h namespace, 07h/08h Format start/completion, 09h/0Ah Sanitize start/completion, 0Bh feature changes, 0Ch telemetry and 0Dh thermal events. Requirements depend on triggering-command and controller conditions.
14.3 · Interpretation and exampleET=0Ah identifies a Sanitize-completion event, not success; inspect its payload result. ETR is not an event count, and supporting a type does not guarantee its presence in this report.
Back to this volume’s figure index15EOM Header
PCIe Transport 1.4 · Figure 75 · EOM Header
§3.9.1.1 · Printed pages 42–43 · PDF 42–43
15.1 · UseBefore analyzing receiver-eye data, inspect the Eye Opening Measurement header for completion, revision and length. A successful log response alone does not establish a completed measurement.
15.2 · Fields and relationshipsEOMIP byte 1 values 0/1/2 mean not started/in progress/completed. HSIZE bytes 3:2 is 64, RSZ bytes 7:4 total bytes, EDGN byte 8 generation and LREV byte 9 is 3 here. DS bytes 23:20 gives descriptor size, ND bytes 25:24 count, and ODP controls optional eye data.
15.3 · Interpretation and exampleND is the actual descriptor count; lane count alone is not a loop bound because a lane can have multiple eyes. Confirm EOMIP=2, advance by DS and preserve the measurement-time link information.
Back to this volume’s figure index16EOM Lane Descriptor
PCIe Transport 1.4 · Figure 76 · EOM Lane Descriptor
§3.9.1.1 · Printed pages 43–45 · PDF 43–45
16.1 · UseEach descriptor describes one eye on one lane. Match measurement identity, success and printable shape without mixing lanes or eyes.
16.2 · Fields and relationshipsMSTAT byte 1 bit 0 indicates success, LN byte 2 lane and EYE byte 3 eye. TOP/BTM/LFT/RGT describe boundaries. NROWS bytes 13:12 and NCOLS bytes 15:14 size the character matrix; EDLEN bytes 19:16 sizes vendor eye data. Printable Eye begins at 32 when present according to ODP.
16.3 · Interpretation and exampleNROWS=5 and NCOLS=7 occupy 35 matrix bytes; when present, subsequent Eye Data starts at 67. A printable 0/1 shape alone cannot establish signal integrity without voltage/time resolution, BER thresholds and other measurement information.
Back to this volume’s figure index
Comments