-
Notifications
You must be signed in to change notification settings - Fork 0
conformance: read the archive, and the loss it admits to #63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
juan-malbeclabs
wants to merge
2
commits into
main
Choose a base branch
from
conformance-read-pcapng
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
Large diffs are not rendered by default.
Oops, something went wrong.
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
Large diffs are not rendered by default.
Oops, something went wrong.
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Blocking — The capture-loss taint has no window: nothing clears
captureDirtyshort of an era advance, so one admitted drop suppresses genuine publisher violations for the rest of the segment. Verified: oneObserveCaptureLoss(1), then 500 contiguous frames with contiguous per-instrument sequences, then a real skip501→552on a gapless frame series — gradedunverifiable/capture_loss, zero violations.Emit's relabelling has the same lifetime: a network gap 260 frames later reportscapture_loss, pointing an operator at the recorder for loss the wire caused.MBP.DELTA.PERINSTR_DENSITYwas previously gated on no taint at all, so this stickiness is new for it. A drop can only explain the first gap after it — clear the flag once the port's frame series is contiguous again.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in 017aa58, and the principle you state is the one I implemented — but at two granularities rather than one, because ending it on frame contiguity alone reintroduces the findings this gate exists to prevent.
The label.
captureDirtyis recomputed per frame and spent on the next frame that advances the series, so a network gap 260 frames later reportsloss.dirtyWindowis deliberately not spent with it: that flag answers "could a gap explain this?", which stays true for the era by design (taintOn), while this one answers the narrower "was the recorder's admitted drop what that gap was?".The density rule. "Clear once the port's frame series is contiguous again" is not a sufficient bound for it. An instrument that updates once every few hundred frames shows its broken chain long after the frame series has recovered, so the drop's own gap is charged to the publisher — most of the 238 findings would come back. I ran that variant against the new test to be sure:
TestTheExcuseWaitsForTheInstrumentThatWasBrokenfails under it withPer-Instrument Seq jumped 1 -> 3graded a Violation, exactly as it fails under the sticky flag.So the density rule's bound is that instrument's own next dense step, which is proof its chain survived the drop.
mbpDensityStatusconsults the instrument rather than the port window and spends the excuse as it grants it, which also restores the invariantstate.goalready claimed — thatcaptureDirtygates nothing on its own and only names the owner.One thing your repro surfaced. Both comparisons are on an epoch counter stamped on each frame at intake, not on the engine's current value. The reorder buffer separates arrival from classification: an admission landing while a frame is buffered belongs to the frame behind it, and comparing against the live counter attributed it to the frame ahead — which arrived before the drop and cannot be what it explains. Without the stamp,
TestCaptureLossNamesTheOwnerOfTheLossbreaks under a window-1 engine for that reason alone.Three tests, all failing on
main: the segment is not silenced, the label does not outlive the drop, and the excuse waits for the instrument that was broken and is spent once.