NVMe · Q1–328

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

Q205–Q216

Persistent Event Log and Timestamp

Retrieve a consistent PEL before interpreting variable lengths, event types and changing time bases.

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

Reporting context differs from persistent history

Persistent events do not guarantee a reusable context after reset.

Retrieval step	Fields	Constraint
Establish view	Action and context status	ACT3 RCE0 can mean newly established
Traverse	Header length, total length, event count	Events have variable lengths
Parse event	Header, event and vendor lengths	Total=EHL+3+EL
Interpret time	Clock attributes and change event	Timestamps need not be monotonic

Worked interpretation: With EHL21/EL20/VSIL4, total length is 44 bytes and event data 16 bytes; adding VSIL again misaligns the next event.

Sources: Base 2.4 §5.2.13.1.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding) · NVM Command Set 1.3 §4.1.4.4 · Base 2.4 §5.2.30.1.8

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

Q205 · How is PEL and individual event support established?
Q206 · How is a PEL context established, read and released?
Q207 · What happens for absent or duplicate PEL contexts?
Q208 · How are key PEL event classes recorded?
Q209 · Which persistent events describe namespace, format and sanitize operations?
Q210 · How are events removed when PEL reaches its limits?
Q211 · Does a new PEL event require an asynchronous notification?
Q212 · What persists in PEL across resets and power cycles?
Q213 · How are PEL headers, lengths and ordering validated?
Q214 · How is Timestamp set and verified?
Q215 · How do Timestamp counting, wrap-around, Origin and SYNC work?
Q216 · How are Timestamp changes and reset outcomes interpreted?

Q205 How is PEL and individual event support established?

Follow the explanation

Establish log support and then event support; PEL support does not require every optional event.

1. Select the target and information

PEL is subsystem-global despite controller identifiers in its entries.

Check LPA, PELS and LID 0Dh support, then the header’s Supported Events Bitmap.

LID: Log Page Identifier

PELS uses 64 KiB units. ECRH supports ACT=3 and GNUM and is required for PEL implementations conforming to Base 2.0 or later.

2. Query sequence and interpretation

Read the header and map mandatory/conditional events before testing.

Obtain an event support matrix rather than one yes/no log result.

3. Handle missing or inconsistent evidence

Unsupported logs follow Invalid Log Page handling; an unadvertised optional event does not invalidate the log.

Figure 233 reserves bits 221:16 while Figure 236 defines ET10h. Preserve this source inconsistency rather than inventing a reconciled bitmap.

First classify the expected event’s support requirement.

Sources: Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13–5.2.13.1.1 · Base 2.4 §5.2.13.1.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding) · Base 2.4 §5.2.30.1.8 · NVM Command Set 1.3 §4.1.4.4 · 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

Back to questions

Q206 How is a PEL context established, read and released?

Follow the explanation

A context stabilizes an event set while a large log is read in segments.

1. Prepare the operation

It is a reporting view, not suspension of event recording.

Check LID 0Dh, ECRH and TLL/LHL/GNUM/RCI.

ACT1 establishes/reads, ACT0 reads, ACT2 releases and ACT3 establishes/reuses with a fixed 512-byte header.

2. Sequence and completion conditions

Read one complete reporting context

Establish the reporting view before reading chunks; later events belong to a subsequent context.

ACT=3 → read the header
Provide at least 512 bytes of buffer and record GNUM, TLL and the reporting context.
ACT=0 → read chunks using LPO
Cover the TLL range while keeping every chunk in the same context.
Recheck GNUM after reading
If unchanged, this consistency condition holds. If changed, the data may be invalid: reread it rather than replacing only the final chunk.
ACT=2 → release the context
Release after a consistent read, allowing a fresh view for the next query.

Preserve ACT, LPO and GNUM per chunk. Successful individual reads do not permit mixing different contexts.

3. Handle unmet conditions

ACT0 without a context or ACT1 with one requires Command Sequence Error; ACT2 without one is not an error.

Sources: Base 2.4 §5.2.13–5.2.13.1.1 · Base 2.4 §5.2.13.1.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding) · Base 2.4 §5.2.30.1.8 · NVM Command Set 1.3 §4.1.4.4 · 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

Back to questions

Q207 What happens for absent or duplicate PEL contexts?

Follow the explanation

This interface does not let the host create a list of contexts with distinct IDs. Command ordering depends on the requested ACT operation and whether a reporting context already exists.

1. Distinguish the failure conditions

Evaluate context existence when the command is processed.

RCE=0 means none existed before processing; ACT3 still successfully establishes one.

Duplicate ACT1 and absent-context ACT0 require Command Sequence Error, not an invented resource-count status.

2. Establish the cause from evidence

Use ACT3 RCE and reporting-port information to inspect an existing context.

Read with ACT0; coordinate readers before release/re-establishment for a fresh set.

3. Outcome and follow-up checks

ACT3 returns a header in either case, with RCE distinguishing prior state; repeated ACT2 release is allowed.

Successful CQE and RCE describing prior state are compatible.

CQE: Completion Queue Entry

First check whether RCE was mistaken for a post-command existence flag.

Sources: Base 2.4 §5.2.13.1.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding) · Base 2.4 §5.2.30.1.8 · NVM Command Set 1.3 §4.1.4.4 · 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

Back to questions

Q208 How are key PEL event classes recorded?

Follow the explanation

Each event has its own trigger and payload; decode type before interpreting fields.

1. When the event exists and who observes it

CNTLID identifies the recorder; shared events should be recorded once and may describe several controllers.

Establish event support; SMART snapshots are required for PCIe implementations supporting PEL.

ET01 carries SMART; 02 commit action/slot/status/requested revision; 03 previous time; 04 reset descriptors; 05 code-selected hardware data.

2. Notification, reading and acknowledgment

Decode ET/ETR/length first. SMART snapshots occur at least once per 24 power-on hours; reset events are logged on completion.

Firmware NFR is the requested revision, not proof of activation; reset FA supplies activation outcome.

3. Evaluate missing notifications or records

Supported qualifying hardware errors are logged subject to suppression; an Invalid Field command error need not be a hardware event.

Correlate CQEs, FR, SMART and payload rather than event names alone.

First check event revision and distinguish requested action from completed effect.

4. Persistent Event recording conditions

PEL retrieval is not itself a PEL read event. Read the complete conditions in this volume

Sources: Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §5.2.13.1.3 · Base 2.4 §5.2.13.1.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding) · Base 2.4 §5.2.30.1.8 · NVM Command Set 1.3 §4.1.4.4 · 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

Back to questions

Q209 Which persistent events describe namespace, format and sanitize operations?

Follow the explanation

Long management operations need distinct start and completion evidence.

1. When the event exists and who observes it

Identify NSID and command-specific namespace or wider scope.

NSID: Namespace Identifier

Check command capability and conditionally mandatory PEL event support.

ET06 records namespace create/delete; 07/08 format start/completion; 09/0A sanitize start/completion. NVM defines FLBAS/DPS interpretation.

2. Notification, reading and acknowledgment

Pair target/action and start/end data; Attach/Detach are not ET06 create/delete operations.

Interpret Format with FNVMS/INFO; entering Sanitize Media Verification is not final completion.

3. Evaluate missing notifications or records

If reset prevented a Format CQE, absent/zero status evidence is not proof of success.

CQE: Completion Queue Entry

FLBAS/DPS are reserved for delete-all; single deletion describes the former format, not an object still available to Identify.

First distinguish start from completion and validate outcome fields.

4. Persistent Event recording conditions

PEL retrieval is not itself a PEL read event. Read the complete conditions in this volume

Sources: Base 2.4 §5.2.13.1.14.2.6 · Base 2.4 §5.2.13.1.14.2.7–5.2.13.1.14.2.8 · Base 2.4 §5.2.13.1.14.2.9–5.2.13.1.14.2.10 · Base 2.4 §5.2.13.1.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding) · Base 2.4 §5.2.30.1.8 · NVM Command Set 1.3 §4.1.4.4 · 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

Back to questions

Q210 How are events removed when PEL reaches its limits?

Follow the explanation

PEL is bounded; not every event is retained forever.

1. Mechanism and scope

Limits may be total bytes, event count or per-category capacity.

Eviction is vendor-specific and may retain older important events rather than strict FIFO order.

2. Understand it through actions and results

Check PELS, TLL/TNEV and vendor policy; current count is not lifetime occurrence count.

Compare complete contexts and account for eviction, frequency suppression and Sanitize.

A valid retained set need not have a monotonically growing count.

3. Avoid a misleading conclusion

Lifetime-sized capacity is a should, not a prohibition on all eviction.

GNUM tracks changed content at context establishment, not total event occurrences.

Source locations for this question

Back to questions

Q211 Does a new PEL event require an asynchronous notification?

Follow the explanation

A new PEL record does not necessarily produce an AER. Persistent recording and asynchronous notification have separate triggering conditions.

1. Conditions for recording and notification

PEL provides persistent history while AER reports eligible asynchronous conditions.

Check PEL support separately from AER/AEC; the event bitmap is not an AER mask.

A critical warning may qualify for both mechanisms; Timestamp Change does not create a generic PEL Changed notification.

2. Build the right verification expectations

Identify the underlying event and then its separate AER type, enablement, masking and request requirements.

PEL-only or dual reporting may be correct depending on the underlying event.

Record separate expectations for logging and notification.

Sources: Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.30.1.6 · Base 2.4 §5.2.13.1.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding) · Base 2.4 §5.2.30.1.8 · NVM Command Set 1.3 §4.1.4.4 · 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

Back to questions

Q212 What persists in PEL across resets and power cycles?

Follow the explanation

Persistent events and temporary reporting contexts have different lifetimes.

1. Identify the trigger and affected objects

Persistence protects subsystem history; a context serves one consistent retrieval.

Save a complete pre-reset view and establish a new context afterward.

2. State changes and recovery

Header time, generation, count and offsets may change, including from a new reset event.

Correlate event identity/content rather than demanding fixed offsets.

Persisted events remain subject to retention rules; an expired context requires a fresh read.

3. Checks across reset or power loss

Trigger	Effect on this operation or state
What survives or continues after Controller Reset?	Event content survives CLR; the reporting context need not. Re-establish it after recovery instead of joining partial data across contexts.
What survives or continues after NVM Subsystem Reset?	Subsystem reset preserves events and may add the supported Power-on or Reset event at completion; establish a fresh consistent reporting context.
What survives or continues after a power cycle?	Events persist across power cycles, with minimal power-failure loss recommended. Capacity eviction, repeated-event suppression and Sanitize-related privacy removal are distinct from ordinary power-cycle clearing.

4. Verify retention and recovery

A stale-context sequence error does not prove erased history; assess eviction, suppression and Sanitize separately.

Validate the complete fresh view rather than only the first entry.

First distinguish missing history from missing context.

Source locations for this question

Back to questions

Q213 How are PEL headers, lengths and ordering validated?

Follow the explanation

One length error can misalign every subsequent variable-length event.

1. Establish the source and scope

Distinguish the whole log from individual events. Log Revision (LREV) identifies the overall log format, while each Event Type Revision (ETR) identifies the format of that event type. Validate both rather than treating them as one version.

Confirm PEL support through Identify Controller.LPA, then read the log header. Total Log Length (TLL) counts log bytes and Total Number of Events (TNEV) counts entries. Log Header Length (LHL) locates the first event, while Generation Number (GNUM) helps detect updates. Establish these bounds before parsing individual events.

2. Fields, units and worked interpretation

LHL starts counting at log byte 20, so the full log header occupies LHL+20 bytes. Event Header Length (EHL) similarly excludes the first three event bytes. Event Length (EL) covers data after the event header and already includes the vendor information counted by Vendor Specific Information Length (VSIL). Total event length is EHL+3+EL; event data excluding vendor information is EL−VSIL.

Advance by validated lengths. With hypothetical EHL=21, EL=20 and VSIL=4, the event is 44 bytes with 16 bytes of event data.

Walk the reported events within bounds; individual events are not guaranteed four-byte aligned.

3. Conditions that change the interpretation

VSIL>EL or an event beyond TLL is inconsistent; transfer alignment does not make events fixed-size.

Newer-first ordering is recommended with vendor-defined occurrence ordering; timestamp changes prevent simplistic numeric sorting.

Source locations for this question

Back to questions

Q214 How is Timestamp set and verified?

Follow the explanation

Timestamp supplies a host time basis for correlation, not a security clock or automatically shared clock.

1. Prepare the operation

It targets a controller; cross-controller correlation needs offsets and reset evidence.

Check ONCS Timestamp support and FID 0Eh saveability.

FID: Feature Identifier

Set uses an eight-byte buffer with a 48-bit UTC-epoch millisecond value; Get adds Origin and SYNC.

2. Sequence and completion conditions

Record host time, await successful Set, then Get Current with elapsed time accounted for.

Origin=001b marks Set Features initialization; value includes counted elapsed time.

3. Handle unmet conditions

Unsupported/invalid/save failures follow feature status rules; a failed Set does not establish an update.

Compare setting, Origin, SYNC and read timing together.

Sources: Base 2.4 §4.4 · Base 2.4 §5.2.12 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.13.1.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding) · Base 2.4 §5.2.30.1.8 · NVM Command Set 1.3 §4.1.4.4 · 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

Back to questions

Q215 How do Timestamp counting, wrap-around, Origin and SYNC work?

Follow the explanation

The same number can represent host-set epoch time or time since reset; interpret attributes first.

1. Establish the source and scope

The 48-bit value belongs to that controller’s time basis.

Read Current Timestamp/TSTMPS and historical changes from PEL.

2. Fields, units and worked interpretation

Origin 000 means reset initialization and 001 host initialization. SYNC0 means continuous millisecond counting; SYNC1 permits omitted intervals.

Establish Origin, then elapsed time; overflow should be reduced modulo 2^48.

Modular differences work within the same basis; SYNC1 prevents demanding wall-clock equality.

3. Conditions that change the interpretation

A smaller value may reflect wrap, reset, saved restoration or a new Set rather than corruption.

Use attributes and change/reset events before ordering timestamps.

Source locations for this question

Back to questions

Q216 How are Timestamp changes and reset outcomes interpreted?

Follow the explanation

Timestamp Change connects discontinuous old and new time bases.

1. Identify the trigger and affected objects

Interpret changes and resets per controller rather than assuming a subsystem clock.

Check support and preserve current attributes, saved value and reset source.

2. State changes and recovery

ET03 header uses the new time; PTSTP records the prior value and MSR the time since CLR.

Relate old/new values, then use MSR and reset descriptors for correlation.

A CLR retaining the running clock preserves Origin; otherwise account for initialization and any saved restoration.

3. Checks across reset or power loss

Trigger	Effect on this operation or state
What survives or continues after Controller Reset?	A CLR method that maintains the running timestamp shall preserve Origin; otherwise apply its initialization/saved-value rules.
What survives or continues after NVM Subsystem Reset?	Check continued counting and Origin per affected controller, not assumed equality across the subsystem.
What survives or continues after a power cycle?	Restoring a saved value can move time backward; uninterrupted counting through power loss is not guaranteed.

4. Verify retention and recovery

A backward clock adjustment does not prove event-order violation; Timestamp shall not use generic ET0Bh Set Feature logging.

Get and change/reset events should support a coherent explanation without assuming all timestamps monotonically increase.

First check clock updates or saved restoration before event ordering.

5. Check notifications and log records separately

Set Timestamp defines no generic success AER or PEL Changed notice. Read the complete conditions in this volume

Timestamp uses its dedicated Change event and shall not be recorded as a generic Set Feature event. Read the complete conditions in this volume

Sources: Base 2.4 §4.4 · Base 2.4 §5.2.13.1.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding) · Base 2.4 §5.2.30.1.8 · NVM Command Set 1.3 §4.1.4.4 · 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) · Base 2.4 §5.2.30.1 (common fields, scope and persistence)

Source locations for this question

Back to questions

Shared rules linked from the answers

Each shared mechanism is explained in full once in this volume. Use browser Back to return to the question; explicit command or feature exceptions take precedence.

Shared conditions for this topic · Is it recorded in the Persistent Event Log?

PEL retrieval is not itself a PEL read event. Supported underlying events follow their triggers, with permitted vendor-threshold suppression of frequent repeated events.

Shared conditions for this topic · Is an asynchronous event generated?

Set Timestamp defines no generic success AER or PEL Changed notice.

Shared conditions for this topic · Is it recorded in the Persistent Event Log?

Timestamp uses its dedicated Change event and shall not be recorded as a generic Set Feature event.

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 · §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.2 (PCIe-applicable events)
Printed pages 183–191 · PDF 209–217 · Figure 150–160
Base 2.4 · §5.2.12
Printed pages 209–212 · PDF 235–238 · Figure 197–202
Base 2.4 · §5.2.13–5.2.13.1.1
Printed pages 212–218 · PDF 238–244 · Figure 203–211
Base 2.4 · §5.2.13.1.2
Printed pages 218–220 · PDF 244–246 · Figure 212
Base 2.4 · §5.2.13.1.3
Printed pages 220–225 · PDF 246–251 · Figure 213–214
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.13.1.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding)
Printed pages 244–256, 258 · PDF 270–282, 284 · Figure 232–244, 246
Base 2.4 · §5.2.13.1.14.2.2, 5.2.13.1.14.2.4
Printed pages 252–255 · PDF 278–281 · Figure 238, 240–241
Base 2.4 · §5.2.13.1.14.2.6
Printed pages 258–259 · PDF 284–285 · Figure 247
Base 2.4 · §5.2.13.1.14.2.7–5.2.13.1.14.2.8
Printed pages 259–261 · PDF 285–287 · Figure 248–249
Base 2.4 · §5.2.13.1.14.2.9–5.2.13.1.14.2.10
Printed pages 261–262 · PDF 287–288 · Figure 250–251
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 · §5.2.30.1.6
Printed pages 466–468 · PDF 492–494 · Figure 474
Base 2.4 · §5.2.30.1.8
Printed pages 469–471 · PDF 495–497 · Figure 479–480
NVM Command Set 1.3 · §4.1.4.4
Printed pages 76–77 · PDF 76–77 · Figure 112

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

NVMe Self-Study Bank: Persistent Event Log and Timestamp

Reporting context differs from persistent history

Questions in this volume

Q205 How is PEL and individual event support established?

1. Select the target and information

2. Query sequence and interpretation

3. Handle missing or inconsistent evidence

Q206 How is a PEL context established, read and released?

1. Prepare the operation

2. Sequence and completion conditions

3. Handle unmet conditions

Q207 What happens for absent or duplicate PEL contexts?

1. Distinguish the failure conditions

2. Establish the cause from evidence

3. Outcome and follow-up checks

Q208 How are key PEL event classes recorded?

1. When the event exists and who observes it

2. Notification, reading and acknowledgment

3. Evaluate missing notifications or records

4. Persistent Event recording conditions

Q209 Which persistent events describe namespace, format and sanitize operations?

1. When the event exists and who observes it

2. Notification, reading and acknowledgment

3. Evaluate missing notifications or records

4. Persistent Event recording conditions

Q210 How are events removed when PEL reaches its limits?

1. Mechanism and scope

2. Understand it through actions and results

3. Avoid a misleading conclusion

Q211 Does a new PEL event require an asynchronous notification?

1. Conditions for recording and notification

2. Build the right verification expectations

Q212 What persists in PEL across resets and power cycles?

1. Identify the trigger and affected objects

2. State changes and recovery

3. Checks across reset or power loss

4. Verify retention and recovery

Q213 How are PEL headers, lengths and ordering validated?

1. Establish the source and scope

2. Fields, units and worked interpretation

3. Conditions that change the interpretation

Q214 How is Timestamp set and verified?

1. Prepare the operation

2. Sequence and completion conditions

3. Handle unmet conditions

Q215 How do Timestamp counting, wrap-around, Origin and SYNC work?

1. Establish the source and scope

2. Fields, units and worked interpretation

3. Conditions that change the interpretation

Q216 How are Timestamp changes and reset outcomes interpreted?

1. Identify the trigger and affected objects

2. State changes and recovery

3. Checks across reset or power loss

4. Verify retention and recovery

5. Check notifications and log records separately

Shared rules linked from the answers

Shared conditions for this topic · Is it recorded in the Persistent Event Log?

Shared conditions for this topic · Is an asynchronous event generated?

Shared conditions for this topic · Is it recorded in the Persistent Event Log?

Source locations and existing figure guides

When you need a field guide

Jia-Chang

Recent posts

Comments