Repository navigation
[Engine] Calibrate: survive an engine dying mid-measurement; adaptive gate: say where the copies stopped (#1337, #2188) - #2935
Closed
dsenchankau wants to merge 1 commit into
Conversation
…easurement (Niko1221#1337 extended) An engine that exits during its own measurement in the worker counts, the expert tier or the shared-expert fork is now that candidate losing, like a failed start already is since 0.1.41: the reason goes into the report's failed_starts list, the other candidates are still measured, and the settings the earlier steps chose are written. A run where no engine dies, and the first start (nothing measured yet), are unchanged. Steps 4-6 share one measure_candidate(); step 6 had no mid-measurement protection at all. The verify-side gate timeout also says where the tier's copy stream stopped (gate words + STRATA_VERIFY_TRACE breadcrumbs) - the open AMD report on Niko1221#2188 lacked exactly that. Tests: tools/test_calibrate.py 30/30 (three new).
dsenchankau
force-pushed
the
preserve-calibration-results-after-crash
branch
from
October 19, 2026 14:04
2e9462f to
cd5c570
Compare
Owner
|
Thanks for the pull request. We're resetting the tracker for 0.2.0-beta. There are more than 1,300 open issues and pull requests, too many for us to review properly, so we're closing everything that isn't being worked on right now. Closed here does not mean rejected. To reopen it takes about two minutes:
The rules are in CONTRIBUTING.md. |
Contributor
Author
|
/reopen |
|
Not reopened yet. Still missing:
Edit the pull request and comment |
Contributor
Author
|
/reopen |
|
The check passed, but GitHub would not reopen it (Validation Failed: ). If the branch was deleted, restore it or open a new pull request and link this one. |
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.
Issue: extends #1337 (shipped in 0.1.41); diagnostics for #2188 (still open)
Problem and result
--calibrate restarts the engine for every setting it measures. Since 0.1.41, a candidate whose engine won't start just skips that candidate and keeps what was measured so far (#1337). But an engine that starts fine and then dies during its own measurement still fails the whole calibration.
I hit this on a UD-Q4_K_XL run: --adapt-swaps 80 measured fine, then the --adapt-swaps 160 engine died at the adaptive tier's copy gate (the same error as #2188). About twenty minutes of --pcie-frac and --spec-min-p results were lost.
After this change a dead engine drops only its own candidate. The earlier settings survive and the winner is picked from what actually measured; in my run 80 swaps beat the default by 10% and was still written even though 160 died. The engine's timeout line for that gate now also prints how far the copies got, which is what's missing in #2188.
Related discussion
#1337 (closed; this extends its rule from failed starts to mid-measurement deaths) and #2188 (open; the engine part here is diagnostics only, it fixes nothing). I don't think this needs a scope agreement first: a calibration where nothing dies behaves exactly as before, and the new C++ code only runs after a wait has already timed out.
Approach
Steps 4, 5 and 6 (worker counts, expert tier, the AMD shared-expert fork) already had the failed-start rule through restart() and failed_starts. I routed a mid-measurement death through the same path and folded the three nearly identical blocks into one restart-and-measure helper. Step 6 had no mid-measurement protection at all and failed the whole run the same way. The first start (steps 1-3) still fails the run; nothing has been measured yet, so there is nothing to keep.
On the engine side, when the adaptive gate's wait times out the message now carries the gate's reached counter, its atomic, and the copy stream's pinned value, and says that the #267 release drains the window's own streams and never the tier's copy stream. With STRATA_VERIFY_TRACE=1 it also dumps the window's trace. Nothing changed for the case where the wait succeeds.
Validation
Revision eb07e55. Ubuntu 24.04, i7-13700F, RTX 4080 SUPER (sm_89), CUDA 13.4 (nvcc V13.4.92, cuda_13.4.r13.4/compiler.38855100_0). I re-ran everything on the upstream main commit this branch is rebased on, as a baseline, and the failing lists below are the same on both.
Passed:
Build is clean. ctest: "96% tests passed, 6 tests failed out of 149". expert_multi_test skips itself on this CPU (no AVX-512). The six failures (ple_parity, ggml_tq_overlay, native_hadamard_test, tq_cpu_parity, tq_cpu_parity_avx2, isa_guard_check) are the same six on the baseline, same command, same build dir. Nothing new fails on this branch.
33 tests, OK. The baseline has 30; the three new ones cover the cases above: a tier candidate dies and the faster candidate still wins, a worker count dies and the rest still measures, a fork candidate dies and the run still returns.
Six failures, the same six on the baseline: test_iq_pack, test_nvfp4_local_pack, test_setup_download, test_setup_engine_hash, test_setup_golden, test_gfx906_qsa_query_swizzle_guard. All environmental, none caused by this change.
Failed: the ctest and python failures listed above. Every one of them reproduces the same way on the baseline, so none comes from this change.
Not run:
Limits
The python tests exercise calibrate.py against a fake engine; nothing crashes a real engine end to end in the tests. And this doesn't fix #2188, it only prints the values its diagnosis needs.