record(LTX25-DEVICE-RESIDENCY): the span-slack bound's fifth and sixth shapes, both MEASURED and both WITHDRAWN (#1727, #1728)

.agents/issue-index.md

@@ -636,3 +636,5 @@ rather than merged. `scripts/check-agent-record.py` gates both.
 | [#1725](https://github.com/mudler/vllm.cpp/issues/1725) | `BACKEND-CUDA-SM110` | `kMatmulFp8Cutlass` and `kMatmulFp8BlockScaled` fall through to the portable CPU tier and SEGFAULT on sm_110 (`test_ops_fp8_cutlass:191`, `test_ops_matmul_fp8_block_cuda:345`, measured at `0764ded2b`). The sm_110 baseline attributed them to [#960](https://github.com/mudler/vllm.cpp/issues/960), which was CLOSED COMPLETED three days earlier by `d607fec4c` -- that fix covered `QuantFp8Static` only, while these two ops are registered from TUs `CMakeLists.txt:1790-1791` builds solely for `VT_CUTLASS_FP8_ARCHS`. `cuda_matmul_fp8_block_cutlass.cu:56-58` asserts they refuse by name instead, which the measurement contradicts; `cffe59b02` has since rewritten that dispatch, and no CI lane can see either way because `cutlass-fp8` is ENABLED on the GB10 gate host | bug |
 | [#1731](https://github.com/mudler/vllm.cpp/issues/1731) | `ENG-RECORD-CONFLICT-SURFACES` | `check-agent-record` is RED on `main`: `#1649` is listed twice in `.agents/issue-index.md`, at `:592` (added by `a7bb3130b`, the lane that FILED it) and `:632` (added by `2f2a70925`, the lane that FIXED it). Neither is wrong and neither could see the other -- `merge=union` combines two appends silently, so a duplicate is the ordinary outcome when filing and fixing happen on different branches, and the checker only notices once both have landed on main, where every later PR inherits the red. Not repaired in flow: the index preamble forbids editing or deleting a row, and the two bodies carry different facts (`:632` has a second red and the mutation evidence, `:592` has the attribution to `a50c57d69`), so choosing which survives is a judgement | bug |
 | [#1733](https://github.com/mudler/vllm.cpp/issues/1733) | `ENG-RECORD-CONFLICT-SURFACES` | CLOSED as a duplicate of [#1731](https://github.com/mudler/vllm.cpp/issues/1731), filed seventeen minutes after it against the same red, and recorded here rather than left unindexed because its one MEASURED claim is FALSE and an append-only row cannot be corrected in place later. Both issues report that `.agents/issue-index.md` lists [#1649](https://github.com/mudler/vllm.cpp/issues/1649) twice on `main` at `038ff61e5`, at `:592` from `a7bb3130b` (the lane that FILED it) and at `:632` from `2f2a70925` (the lane that FIXED it). #1731 is the earlier filing, already carries an index row, and is the record. #1733 adds one thing #1731 does not, and it is wrong: "the repair is measured and it is NOT blocked", on the evidence that removing one of the two rows in a worktree and running both checkers gives `agent record OK: ENGINE=170 MODEL=377 ...` and `OK: issue index append-only`. The second half is an artefact of the instrument. `scripts/check-issue-index-append-only.py:50-51` diffs `merge-base(origin/main, HEAD)..HEAD`, which reads COMMITS, so an UNCOMMITTED deletion is invisible to it. Measured on `row/FIX-ISSUE-INDEX-1649-DUP` at base `038ff61e5`: deleting `:592` in the WORKING TREE alone returns `OK: issue index append-only` at rc 0 with `git diff --numstat 038ff61e5..HEAD -- .agents/issue-index.md` EMPTY, and committing the byte-identical deletion turns the same checker rc 1 with a `removed:` line naming the row. #1733's own quoted `agent record OK: ENGINE=170 MODEL=377` is the tell, because that is the working-tree reading and the committed tree cannot produce it while the duplicate stands. So the duplicate IS base-reachable, the two checkers ARE in genuine contradiction on this tree, and the repair is the argued exception #1731's row anticipated rather than the free edit #1733 reported | bug |
+| [#1727](https://github.com/mudler/vllm.cpp/issues/1727) | `LTX25-DEVICE-RESIDENCY` | **CONSTRAINT ON ANY RE-PROPOSAL of a sampler-based span-slack denominator, which is NOT on `main`: the boundary sampler carries three terms and a gate can falsify only one.** The estimator this row built was measured and WITHDRAWN -- see [`ltx25-device-residency.md`](specs/ltx25-device-residency.md) `### The span-slack bound, FIFTH and SIXTH shapes` -- so what follows is what anyone rebuilding it already owes. `InstrumentCeiling::Loop` timed the process-wide mutex, `SampleNow()`'s `/proc/self/statm` read, and one flushed write standing for `EmitLocked`. A fresh review of [PR #1712](https://github.com/mudler/vllm.cpp/pull/1712) deleted the flushed write entirely -- the term the derivation argues corresponds to the live lane's per-boundary line -- and the case stayed GREEN 3 of 3 at `compile_status=0`, `assertions: 606 \| 606 passed \| 0 failed`, with the ceiling reading 3.24-9.19 ms against an unmutated range of 0.94-17.5 ms: nothing distinguishes the term's removal from run-to-run noise. That same measurement is what freed the write to be pointed at `/dev/null` instead of fd 2, where at 1 kHz it corrupted 27% of the `[render]` lines [#1413](https://github.com/mudler/vllm.cpp/issues/1413) exists for (158 occurrences in one capture, 116 beginning a line) -- **but that redirect went out with the withdrawn shape and is NOT in the tree**, on `origin/main` or on this branch, so #1413's stream corruption is UNFIXED and nothing here may be banked against it. What stands is the measurement, not a repair: the sink is not what the term measures. TWO further halves of the estimator are UNMEASURED rather than ungated. The SANITIZER lane: the third shape of this bound needed its own constant under ASan and TSan because a sanitizer instruments the scope boundary this quantity IS, and the sampler now inherits that automatically by compiling into the same binary -- but the sample count grows with the slowdown too, so the maximum is drawn from a deeper quantile, and nobody has run `sanitize-cpu` against the estimator (the review could not: a second full build tree does not fit at 93% disk). The FULL-SUITE regime: [#1576](https://github.com/mudler/vllm.cpp/issues/1576) measured this quantity at 3.223 ms inside the full 102-case `ctest` run against 18.8 us under a `-tc=` filter at comparable load, **171x**, and that swing is the whole reason the constant was declared unsafe -- yet both the row's 120-run validation and the review's 24-run one were taken almost entirely under `-tc=`. One full-binary run (containment case as #40 of 102) was indistinguishable from the filtered ones at ceiling 2.31 ms, bound 9.22 ms, worst slack 86 us, so the 171x did not reproduce at n=1. NOT FIXED IN FLOW: gating a term of the estimator is a second instrument over the first, and each unmeasured regime needs a build tree this box cannot hold beside the one it has. What would settle it: one `sanitize-cpu` build with the containment case run 40+ times, and one 40-run population through the FULL binary, both reported as distributions. Owned by [`ltx25-device-residency.md`](specs/ltx25-device-residency.md) `## Owed` | verification |
+| [#1728](https://github.com/mudler/vllm.cpp/issues/1728) | `LTX25-DEVICE-RESIDENCY` | **HYPOTHESIS, filed unmeasured and labelled as such, and a CONSTRAINT ON ANY RE-PROPOSAL rather than a live defect, because the sampler it is about was measured and WITHDRAWN and is not on `main`: on a ROCm runner a 1 kHz boundary sampler inside `(1c)` would call `hipMemGetInfo` 1000 times a second under the process-wide phase mutex.** Raised by the fresh review of [PR #1712](https://github.com/mudler/vllm.cpp/pull/1712) on a CPU-only box with no GPU lease taken. `InstrumentCeiling` runs a thread calling `vllm::multimodal::phase::SampleNow()` once per millisecond for the whole of `ltx2 video: the three carrying phases contain their work and the load keeps its order` -- 3,764 to 27,975 draws per run, measured. `SampleNow()` takes the phase mutex and runs `SampleLocked()`, which invokes the installed `DeviceByteProbe`; `FixtureParams` sets `mp.device = 0` and `src/vllm/multimodal/ltx2_video.cpp` installs a probe calling `vt::Backend::DeviceMemoryInfo`. On the lanes the review could run this is harmless because `CudaBackend` does not override it and returns the -1 sentinel ([#1126](https://github.com/mudler/vllm.cpp/issues/1126)), but `src/vt/rocm/rocm_backend.hip:373` DOES override it. If the reading is right the consequence runs in two directions at once: the render slows because it contends for that mutex against a thread holding it across a driver round trip, and the sampler's own draws inflate, widening the very bound (1c) asserts against. What would settle it, cheaply: one lease on a ROCm device running that case and comparing the printed whole-case boundary median and maximum against this box's 18.4-22.9 us / 0.94-17.5 ms, plus the case wall. If it reproduces, the repair is a null device probe for the sampler's lifetime, or a device-counter cadence far below the boundary-timing cadence. NOT FIXED IN FLOW: the box that found it has no ROCm device and the session was CPU-only, so both reproduction and repair are unmeasured. Filed rather than left in a review transcript, because a 1 kHz driver call under a shared mutex is the kind of thing discovered as "the ROCm CI is slow" months later. Owned by [`ltx25-device-residency.md`](specs/ltx25-device-residency.md) `## Owed` | bug |