Repository navigation
Mac show drill exceeds media-core-sync p99 gate on unchanged native source #1178
Description
PR #1176 head 864e903 failed the mac-show-drill on macos-15: media-core-sync p99 135.9 ms exceeded the existing 100 ms operator-response gate. Run 42228684189, job 127928650197, November 6 13:54–13:57 UTC. Retained log: D:/CoreVideo-QA/resume-20261106/1176-mac-show-failure.log.
The final render windows reported worst intervals up to 85.8 ms and variable content cadence. This is a real failed sample; no initiating cause is established. The PR changes Windows workspace lifetime code and documentation only. Its native/Mac/harness sources match the base, and the same source passed the Mac show drill on #1174/#1175 earlier in this window. That narrows patch attribution but does not establish runner contention or justify raising the threshold.
Investigate the failing timing samples/stage attribution and compare a bounded exact-source repeat or baseline. Preserve the original failure and all repeat outcomes. Fix any demonstrated product or harness initiating condition; do not retry until green or relax the p99 gate. Related general timing work #517; this is distinct from the Windows eight-ISO Program miss #1177.
New intake for the authorized replenishing window. Keep it tracked while the Windows teardown PR completes its local compiled validation; no claim that the teardown fix caused a Mac media change.
Activity
iamfatness commentedon Nov 6, 2026
The Mac show-drill failure recurred on the Tiles qualification PR #1180 head 61727d2. Job 127983704547 actually executed after a separately retained zero-step runner-allocation cancellation. The real result is FAIL: operator command p99/worst 240.4 ms (51 syncs), p50 6.1 ms, threshold unchanged at 100 ms. Recorded rate was also a measured 37.3/60 fps failure under the existing advisory option. Render missed 146 deadlines and skipped eight slots in the recording interval; zero encoder queue drops does not erase those failures.
Retained full log: D:/CoreVideo-QA/resume-20261106/1180-mac-show-failure.log. #1180 changes only the Windows-guarded Tiles fixture and specification, so this is further evidence of a pre-existing or environmental timing condition, not proof of its cause. The exact PR gate remains failed and the merge is held. No retry-until-green or threshold change. Next investigation needs per-command step identity and contemporaneous timings; the existing summary retains only aggregate request type/latency and final render windows.
iamfatness commentedon Nov 6, 2026
New instrumented hosted evidence at a290c39: Mac job, timing artifact.
Both command-latency samples passed the unchanged 100 ms gate: normal p99/worst 37.691 ms (51 syncs), loaded p99/worst 26.884 ms (51 syncs; 52 total requests). No timeout or report-bound omission occurred; both readers drained. The native appendix now includes command queue/capacity/core/handler, response assembly and writer phases. Native logger counters reached four dropped records in each sample, so captured phases remain incomplete even though the report itself omitted none.
The normal worst request spent 20.767 ms parsing after reader receipt; the loaded worst spent 14.678 ms parsing and 7.540 ms in caller continuation. These observations do not explain the earlier 103.0/135.9/240.4 ms failures. Stderr receipt adjacency is not exact native request correlation. No causal repair or closure is claimed; #1180 remains held.
The green job is not a performance pass. Normal recorded rate was 34.7 fps under its existing advisory flag. The loaded drill failed at 39.1 recorded fps and 23 dropped render slots, with a 70.6 ms worst frame; the pre-existing continue-on-error policy leaves the GitHub job green. Full logs and both outcomes are retained. No threshold or request population was relaxed by this work.
Local evidence: D:/CoreVideo-QA/resume-20261106/1178-native-phase-hosted-a290/, 1178-native-phase-mac-a290.log and 1178-native-phase-analysis-a290.json. The five controlled subprocess cases pass after main integration; disabling actual diagnostic retention fails the added case. Next action is to complete exact-head checks and retain the bounded diagnostic capture for a future genuine failing sample, rather than retry until a green sample is called a fix. This follow-up stays out of beta-2026-11-06-74495ad.
diagnostics: retain early render phase evidence for #1178
iamfatness commentedon Nov 6, 2026
The first failing sample with native phase capture is now retained: head
cea2b30dccdb43cbe8cab7c500a69abcb6c2d50d, run 42284929309, artifact 13536699426.The first request, enable-diagnostics, takes 199.222 ms against the unchanged 100 ms limit. Its adjacent native request record reports 186.117 ms waiting for the core lock, 2.147 ms handling, and 0.594 ms command queue time. Response projection/serialization are 3.586/2.377 ms; parsing/caller continuation together are 3.649 ms. The simultaneous render STALL reports 289 ms rendering. This strongly identifies core-lock wait as the dominant boundary in this sample; it does not yet establish the initiating render/GPU operation or explain every historical failure.
All 52 requests remain in the population. No timeouts, no bounded-report omissions, both readers drained. Two native logger records were dropped later in the run, so phase evidence is incomplete. The same run also fails render-over-budget acceptance; recorded rate is 34.3 fps. The loaded step did not execute after the normal step failed. No unchanged retry was requested.
The first command begins 1.552 seconds after process start. Later aggregate diagnostics report a 1.417-second worst render hold, but the appendix discarded startup render/lock records. PR #1182 now retains the existing render, lock-guardrail and lock-hold-attribution prefixes within its unchanged 512-record cap. A controlled child emits phases before its first response: the old filter fails with zero retained records versus two expected; the new capture passes all six subprocess cases and the actual script-gate wrapper. New head
a52f5e5achanges only evidence capture, its tests and the specification. Native implementation, startup request population, thresholds and counters are unchanged.Next evidence requirement: capture the early render phase, reproduce its initiating operation with a bounded control, and only then change production scheduling/initialization. Keep #1178 and dependent #1180 open/held. A green follow-up sample cannot close this defect. All local reports and negative/restored tests are retained under
D:/CoreVideo-QA/resume-20261106/1178-*; the published Windows beta remains frozen at74495ade.iamfatness commentedon Nov 6, 2026
The startup-retention change now has hosted evidence at
a52f5e5ad97972758a4201321a64bc360e5bb6e1: run 42287064252 / Mac job, artifact 13538077232.The normal run's first render slot holds the core lock for 1,083,686 us, of which 1,083,429 us is Program. Its diagnostic arrives at 1,105.37 ms, before the unchanged first command. This record was lost by the previous filter. The subsequent loaded process's first hold is 32,229 us (Program 32,157 us). Different process/cache state is a hypothesis, not a controlled explanation. Source review shows lazy Metal shader/pipeline/target creation inside Program render; the phase record does not separate those operations from GPU admission or execution.
Normal sync p99/worst: 25.269 ms across 52 syncs. Loaded sync p99/worst: 22.488 ms across 51 syncs. The loaded synthetic-join request is a different request type and takes 295.708 ms; it remains retained in the report, but is not silently added to or removed from the pre-existing sync-only gate. There are no report omissions, both readers drain, and native logger loss is two records normal / five loaded. The 199.222 ms failed sample remains retained; this green command sample is not its repair.
Performance is still failing: normal recorded rate 33.1 fps (advisory in existing policy); loaded recorded rate 38.9 fps, 22 dropped render slots in the final printed window, worst interval 65.9 ms. The loaded step reports SHOW DRILL FAILED under the existing continue-on-error policy, so the green job is not full performance qualification.
The next production experiment must distinguish pipeline initialization, target allocation, GPU admission and completion within the measured Program phase. If cold initialization is confirmed, use the existing pre-worker preparation boundary and test actual first-frame pixels plus command availability, without moving already-required output out of the measured population. Secondary monitor waits and steady-state failures remain separate measurements. Do not assume that startup preparation alone fixes all observed delays.
Separate source-review intake #1195 tracks unchecked Metal semaphore timeout; it is unranked and is not asserted as the cause of these samples. #1182 remains diagnostic coverage outside the published Windows beta. Exact-head Windows checks remain pending. Local evidence:
1178-startup-phase-hosted-a52/, its job log, and1178-startup-phase-analysis-a52.jsonunderD:/CoreVideo-QA/resume-20261106/.diagnostics: retain Mac command and native phase timing (#1178) (#1182)
iamfatness commentedon Nov 6, 2026
Diagnostic coverage in #1182 merged as
9ab601f98f04660081d6770abf7f1de20343b5bdafter all 17 current-head checks passed ata52f5e5ad97972758a4201321a64bc360e5bb6e1; prerequisite #1193 was already merged. The initial merge guard found GitHub's mergeability state UNKNOWN and made no mutation; after GitHub reported MERGEABLE, the same head passed the full guard and merged. Both snapshots are retained.This does not close #1178 or qualify held #1180. The captured 199.222 ms failure locates 186.117 ms in core-lock wait. The later startup capture retains a 1.084-second first Program phase. Pipeline/target initialization versus GPU admission/completion still needs controlled separation before a production latency fix. The normal and loaded sync gates pass in the latest sample, while the loaded performance step still fails under the existing advisory policy. Its 38.9 fps recording, render misses and native logger loss remain retained and are not converted into a pass by the green job status.
The actual report reader now retains early render/lock phases, late native timing, explicit omissions and native logger loss within fixed bounds. Six controlled subprocess cases and the real script-gate wrapper pass; old-filter and disabled-retention negative controls fail as expected. No performance budget, request population, frame-quality setting or startup filter was relaxed.
Current next-step specification and evidence are in the preceding comments and
docs/reference/mac-command-attribution-1178.md. Separate unranked #1195 covers unchecked GPU admission timeout; #1194 covers the two-frame startup miss. The published beta remains frozen at74495ade. Final merge/check snapshots and Windows log are retained underD:/CoreVideo-QA/resume-20261106/pr-1182-*and1178-final-windows-shell.log.