feat(perf): zc_confirm_reject counter — perf struct v3#28
Merged
Conversation
Salvaged from the refuted PWM-blanking PR (#23): a monotonic counter on the zero-cross confirm loop's reject path, the live monitor for the F051 glitch-tolerant confirm (#21). delta(reject)/delta(zc_count) over a window = rejected edges per accepted commutation - rare in clean running, balloons under real comparator noise, so it turns 'the tolerance is working' from an inference into a measurement. Struct v3 (84 B): one u32 appended after the v2 jitter block; host_cmd stays frozen at offset 60. Host decodes v1/v2/v3 (compiled v2-ELF regression fixture included); confirm_rejects_per_zc reported per steady point (report-only). Counter increments on both the F051 tolerant early-out and the generic strict-loop reject, compile-gated to nothing in production builds. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The instrumentation salvaged from #23 (per its bench verdict), without any of the blanking: a monotonic counter on the zero-cross confirm loop's reject path, giving live visibility into the #21 glitch-tolerant confirm.
Δreject/Δzc_countover a window = rejected comparator edges per accepted commutation — rare in clean running, balloons under real noise — so "the tolerance is working" becomes a measurement instead of an inference.Contents
hwci_perfstruct v3 (84 B) — one u32 (zc_confirm_reject, offset 80) appended after the v2 jitter block,host_cmdfrozen at 60 per the versioning contract.HWCI_PERF_CONFIRM_REJECT()fires on the F051 tolerant loop's early-out and the generic strict-loop reject; compiles to nothing withoutHWCI_PERF. Production builds byte-identical.perf_zc_confirm_rejectCSV column,confirm_rejects_per_zcper steady point (report-only,Noneon pre-v3 firmware), sim support.Version bookkeeping
Not bench-tested per @AlexKlimaj — instrumentation-only, no behavioral change, and the identical counter ran on the bench inside #23's builds during the A/B session without issue.
🤖 Generated with Claude Code