Repository navigation
Conversation
H62's re-run trigger fired: EAT release-2.0.0 was tagged (7b827e2d) and EAS
v1.2.0 was released (a051f00f), naming enterprise-inference v1.1.0 (d035b1ef).
H62r is the new row H62 named for that case: H62's hypothesis and predictions
copied verbatim (B5's release identifiers aside), A1 unchanged, and H62's
design, statistic, gates, caps, budget and verdict rule, with its own L3 seed.
Between H62's commits and the GA tags only docs, VERSION, the layer manifests
and enterprise-inference's LiteLLM changed, so the sizing that starved EAT's
sandbox router in H62 is the same code. The pre-registration traces it before
any measurement: EAS's topology probe counts the comma fields of cpu0's
thread_siblings_list, reads the guest's adjacent pair "0-1" as one thread per
core and falls back to its standard reservation (12 CPUs), so cpu: auto gave
gemma-4-26b 76 CPUs. On crescent's host ("0,48") the probe reads two and EAS
reserves the 48 siblings. A spike in a KVM guest of H62's shape reproduces the
read with EAS's own probe (bench/h62r/topology-spike.sh).
bench/h62r/ starts as a copy of bench/h62/, which stays untouched. Changes:
the GA pins (Docker CE in VM a at its current patch release), H62r's own
guests, ports and state, D1 as a check of the GA manifest, D3's sibling read
(nri_reserved_cpu_list in global_config.yaml, EAS's documented setting, only
when the probe reads one thread per core where the kernel lists two), sizing
records in VM b whether the install passes or fails, a check that A1's render
carries H50's OVMS image, main's EAS check in the smoke, a bound of 3 setup
attempts, and the trigger's thresholds after the GA releases. pairs.py and
live.sh learn H62r; pins/classes classifies bench/h62r and adds H62r to the
harness lines that list H62; the technical report counts 83 rows and 10
PENDING. Nothing is measured here.
…fore each hold The pre-registration says the trigger runs before setup and before each hold, with its output in the records, and that a trigger fired before hold 1 needs a dated amendment re-pinning B5 before that hold. campaign.sh never ran upstream.sh, so nothing enforced either. It now reads the trigger (up to 3 reads, 60 s apart) into upstream.txt before setup and before each hold. Fired or unreadable before setup: exit 11 before anything starts, with no setup attempt spent. Fired before hold 1: exit 11 with no hold. Unreadable before a hold, or fired after hold 1: recorded, and the holds go on at these pins. The ledger's trigger and reproduce text say the same.
…stream note names both reads EAS v1.2.0's probe reads thread_siblings_list twice. The pre-registration covered its threads per core (line 31) but not its sibling list (line 74), which takes a list's first comma field as the core's lowest thread. In the guest that field is the range "0-1", so NRI_SIBLINGS names all 96 vCPUs. topology-spike.sh now prints that line too; run again on the desktop (QEMU 10.2.1, -smp 96,sockets=1,cores=48,threads=2, the probe at a051f00) it printed NRI_SIBLINGS=0,1,...,95. So the upstream note's fix (count the cpulist with ranges expanded) was incomplete: with only the count changed, the siblings profile would reserve every vCPU, because it reserves NRI_SIBLINGS as read. The note now names both reads. D3's cpuset is described as the set the probe defines as siblings, read with ranges expanded (what EAS reserves on crescent's host), not as what EAS would reserve in this guest; with nri_reserved_cpu_list set the role does not read NRI_SIBLINGS. The risk list says the probe's records will show all 96. No prediction, gate or cap changes.
The technical report's status line and PENDING count conflicted: main moved H52w from PENDING to SUPPORTED, and this branch adds H62r as PENDING. The report now names the H52w run, 83 rows, and 9 PENDING rows with H62r first.
…lier smokes intact across attempts Three runner gaps found in review, each with a test that failed first. - arm.sh records now writes image-ids.txt, the image ID of every container in the guest. The pre-registration's risks say each hold records the sandbox router's image ID (EAT's floating staging tag), and no record carried one: pods.txt is `-o wide` and pod.json is the serving pod's. - campaign.sh refuses to start (exit 11, not counted as an attempt) once a hold<N> directory exists. It numbers holds from 1, so a later attempt after a hold would have written over hold1/ and runs/H62r-hold1/ and restarted the count of 8 holds. - smoke.sh moves an earlier attempt's smoke/H62r and runs/H62r-smoke aside before it starts. warmups.jsonl is appended, so after a first smoke whose hold answered both warm-ups, every later smoke read 4 of 2 and failed, and validate.log and eat-check.log of the earlier smoke were overwritten. The H62r section says the same for the setup bound and the smoke.
…its stderr campaign.sh captured upstream.sh's stderr with its output, so a warning from git ls-remote next to "fired: none" would have read as a fired trigger and stopped the campaign. It now reads only the "fired: ..." line on stdout; a read without that line counts as unreadable, and the errors go into upstream.txt.
Both changes touch campaign.sh's start. The hold guard (a start after any hold exits 11) runs first, then the attempt bound (exit 10), then the trigger before setup. The trigger's stops now exit 12, so each exit code names one cause; the tests say the same.
…ot from crescent Item 3 said the probe's sibling read gives 48,...,95 on crescent's host. That value comes from running the probe on a sysfs tree with the host's numbering; crescent was read only for cpu0 and cpu1. The sentence now says so.
reserve() matched the nri_reserved_cpu_list line only without a trailing comment, so a live line like `nri_reserved_cpu_list: "" # ...` was missed and a second key was appended after it, and a commented line holding another cpuset was not refused. It now reads any live key line (double- quoted, single-quoted or bare value, optional comment): an empty value is filled, the same cpuset is left alone, and any other value or an unreadable line stops the setup. EAS v1.2.0's seeded global_config.yaml carries no such line, so this run was not exposed. The comment it appends now describes the cpuset as the probe's siblings, as the ledger does.
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.
Pre-registers H62r, the row H62 named for its re-run trigger, with its runner and tests. Nothing is measured, nothing runs on crescent, and this PR is not to be merged by its author.
Why now
H62's trigger fired:
bench/h62/upstream.shreadsfired: eas v1.2.0, eat release-2.0.0. EATrelease-2.0.0is tagged at7b827e2d, and EASv1.2.0(GA,a051f00f) names enterprise-inferencev1.1.0(d035b1ef). H62 stays INCONCLUSIVE with its records untouched;bench/h62/**is not modified.The row
H62r-crescent-2026-11-06.Mechanics for
cpu: autostarving the sandbox router, registered before any measurementFrom H62's commits to the GA tags, only docs,
VERSION, the layer manifests and enterprise-inference's LiteLLM (v1.84.0) changed. The sizing that failed in H62 is the same code. Traced from source:thread_siblings_list.0-1: one thread per core. Thesiblingsprofile then falls back tostandard(12 reserved CPUs), andcpu: autogives gemma-4-26b 96 - 12 - 8 = 76 CPUs. That is H62's failure.0,48(read-only ssh). The same code reserves the 48 siblings and gives 40 CPUs, which leaves room for the router.bench/h62r/topology-spike.shreproduces the guest read with EAS's own probe ata051f00, in a KVM guest of H62's shape:NRI_TPC=1,NRI_PHYSICAL=96.D3's sibling read applies only when EAS's probe reads one thread per core and the guest kernel lists two. It sets
nri_reserved_cpu_listinglobal_config.yaml, EAS's documented setting, to the guest's 48 sibling vCPUs. That is the reservation EAS's default profile makes when it reads SMT. Expected, not gated: gemma-4-26b at 40 CPUs. Every other combination stops the setup for an amendment. Setup is bounded at 3 attempts.Runner
bench/h62r/starts as a copy ofbench/h62/, with these changes:eas-checkin place ofeas-pinsibling-readandreserveintegrations/eat/eat-check.shandeas-ready.pyin the smokebench/eatflow/pairs.pyandlive.shlearn H62r.pins/classesclassifiesbench/h62r/**and adds H62r to the harness lines that list H62. CI runsbench/h62r/test_h62r.py.docs/intel/technical-report.mdnow counts 83 rows and 10 PENDING.Checks run locally
bench/h62r/test_h62r.py: 66 tests, OK. The skip is shellcheck-in-test; shellcheck v0.11.0 ran separately and is clean at warning level.bench/eatflow/test_pairs.py(74),test_agentbench.py(95),bench/h62/test_h62.py, the crescent, solo and H58 suites: all OK.tests/ledger_drift_check.py(83 rows),tests/claims_check.sh, their tests, andtests/ledger_freshness_test.py: all pass.hack/pin-classes coverage,tests/pin_classes_test.py,hack/pin-guard --base origin/main,tests/pin_guard_test.sh,hack/pins checkand actionlint: all pass.Upstream note
EAS's probe misreads threads per core on any node that writes a core's threads as a range. This is a finding for Intel's EAS team; nothing is filed from this PR.