Repository navigation
bench(probe): R2 batch-control record, attempts 1 and 2 (RTX 5070) - #1714
Merged
Merged
Conversation
…e the rule batch_control_probe.py runs the R2 batch control: one stream_probe.py process per arm, SINGLE and STRIPED at batch 1, 2 and 3, two rounds (the second the exact reverse of the first), after a CPU-only cache check, a build arm and a 300 s settle. It imports the two-drive gate's stamps, pre-arm checks, power/PDH sampler and void rule unchanged, requires an empty card (0 MiB) before every arm, voids an arm another process read 1 GB during, and runs the read-free floor (--ablate --arms B_nocopy) after every SINGLE arm's step block. An out-of-memory error, an arm past a 600 s cap, or a spill (the card as full as what-bounds §18's spill and the step slower than read plus compute in series) is a result that skips the larger batches of that layout, not a void. batch_control_rule.py is the record's rule from the committed files alone (--summarize). batch_control_sampler.py adds nvidia-smi every 2 s and the Windows GPU memory counters every 1 s, per adapter and for the arm's own process. stream_probe.py, outside the timed region: each timed step records its wall-clock start (started_unix; the same four lines as 6ee60ce on probe/two-drive-sustained, so the branches merge cleanly); an out-of-memory error inside a --step or --ablate block is written as an "oom" point and the run exits 3; every step point carries a SHA-256 per row of its token ids and the allocator's counters. Nothing has run: two --dry-runs into a scratch folder, a synthetic check of the rule on fake arm files, and a mocked run of the arm flow (fake arm processes that only write JSON). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
probe-rtx5070-batch-control.md asks whether tok/s on the cold 70B-shaped NF4 step at seq 512 scales with batch 1 -> 2 -> 3 as the read-bound model of what-bounds §21 predicts (the step is the larger of the read and B(S) = 1.241971 s + 0.0101240 s x S), on one drive and on two striped drives, and what peak VRAM each batch needs on the 8 GB card. The rule (§2), per layout and batch: validity rows for the SINGLE batch-1 step (15.0-21.5 s, the gate's band), the path under test (including the exact SINGLE cache folder and identical token rows across the arms of one batch) and the STRIPED batch-1 step (7.69-12.0 s); a fit row (out of memory, a 600 s cap, allocated above the card, or a spill: 7,620 MiB in use, §18's spill reading, and the step slower than read plus compute in series); the class of the two-round mean of step(b1)/step(b) (NEAR-FREE >= 0.95, NONE when b x e <= 1.05, else PARTIAL); and that class against the model's. Every threshold is quoted from a committed record. Power and SM clock are recorded and not judged: the two spills on record on this card disagree on the clock (§18 at 1.8 GHz, gate-836 §8 at 2782 MHz). The model predicts one drive near-free to batch 3 and two drives compute-bound from batch 2, so the second drive would be worth about 4% at batch 3. The SINGLE arms are the L2L step-0 control (§1, §1a); they run PR #1536's per-drive reader with one drive at 2c6ed08, not origin/main's. §4 holds the complete commands; the run belongs to another session. Results pending. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ds as measured) Run from 5a4df9be (the rule commit) on 2026-10-01 23:35, --plan all. Position 0 (SINGLE b1) was void twice: a SearchIndexer.exe read of 4.94 GB, then a 14.6 h laptop suspend right after the re-run started. By the rule's own text a second void in one position stops the sequence and row 2 gives no verdict; no round arm was judged. Every file is kept as measured, void arms under _void/_void2. Section 5.1 records what the files say, including what they do not: C: read at a steady 2.0-2.2 GB/s in the first arm (about half of section 21's rate), the indexer is ~1.8% of that traffic and is not shown to be the cause. The rule (section 2) is untouched; attempt 2 runs whole with a new --run-prefix. The repo's pre-commit hooks added a final newline to the raw JSON files and trimmed one trailing space in a log line; nothing else in the data changed (a whitespace-insensitive diff against the driver's output is empty). Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…L (DISAGREES AT b3); STRIPED b2/b3 PARTIAL (AGREES) Attempt 2 of the batch control (--run-prefix batch2), 2026-10-07 10:15:46Z-10:45:52Z, from aef2d31a (src/ byte-identical to 2c6ed08 and to the merged #1536 head 0130e02). Rows 1-3 did not fire; the rule (section 2, unedited) judged both layouts: - SINGLE (R 18.327 s): b2 NEAR-FREE e 1.027 (1.068, 0.985), AGREES; b3 PARTIAL e 0.899 (0.938, 0.861), DISAGREES AT b3; no labels; crossover (1024, 1536] tokens against the model's 1688; batch 3 fits (6.312 GB allocated, 6876 MiB). - STRIPED (R 8.839 s): b2 PARTIAL e 0.713, b3 PARTIAL e 0.497, both AGREE; crossover (512, 1024] against the model's 750. One void (round 0 SINGLE b3: BackgroundDownload.exe read 3.10 GB), re-run once in place as section 4 prescribes; its files are kept under the _void name. Windows Search was running (the owner had not stopped it); the run started after SearchIndexer.exe read 0 bytes for 5 min 16 s, per the 2026-10-04 ruling, and it was not a top reader in any arm. Records as measured; section 5.2 and section 6 written from the rule's output. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
MakazhanAlpamys
added
the
ci:full
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
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.
Measurement record, published as measured. Nothing in the rule or the numbers was changed after the runs.
What this is. The R2 batch-control probe on the RTX 5070 Laptop (8 GB) box: does a larger micro-batch recover the read-bound step on the disk tier, on one NVMe and striped over two? The rule (
benchmarks/probe-rtx5070-batch-control.md, section 2) was committed before the first run; the driver and the GPU samplers are inbenchmarks/harness/.What it records.
benchmarks/results/probe-rtx5070/batch-control/.Scope. Only
benchmarks/changes; no source, no docs. The four commits are the ones made during the runs, re-parented onto currentmainbecause the branch had been cut from the two-drive striping branch that #1536 squash-merged.Next. None for this record. A later probe appends a new section; the sections here stay as they are.