Bump ethrex to 26.0.0 and rebuild the benchmark workload

.github/workflows/bench-abba.yml

@@ -9,27 +9,38 @@ name: Bench ABBA tiebreaker
 # Syntax: "/bench-abba [N]", where N is the pair count (default 12).
 #
 # Resolution, from the paired t-test (resolvable 95% delta = t* x sd / sqrt(N)). The
-# pair-delta sd on this runner is NOT yet measured; the two columns bracket it between
-# 1.0% (the GPU box's measured 0.64% plus margin) and 2.0% (sqrt(2) x this runner's
-# measured 1.43% single-run CV):
+# two columns are not a guess bracketing an unknown: they are the same runner under
+# two conditions, because its variance is contention and not prover jitter. Over a
+# 14-prove baseline (tooling/ethrex-fixtures/README.md) wall time and the share of CPU
+# a prove actually got correlate at -0.98, perfectly monotonic, so the single-run CV is
+# 0.34% across the proves that got the most CPU and 1.26% across all of them. sd of a
+# pair delta is sqrt(2) x that:
 #
-#   pairs   wall      resolves (sd 2.0% / sd 1.0%)
-#    8      ~50 min    1.7% / 0.8%
-#   12      ~72 min    1.3% / 0.6%   <- default
-#   20      ~1h55m     0.9% / 0.5%
-#   32      ~3h        0.7% / 0.4%
+#   pairs   wall      resolves (quiet box, sd 0.49% / shared, sd 1.78%)
+#    8      ~41 min    0.34% / 1.24%
+#   12      ~58 min    0.28% / 1.01%   <- default
+#   20      ~1h31m     0.21% / 0.78%
+#   32      ~2h22m     0.16% / 0.62%
 #
-# Wall is 2 x 158.8 s per pair (the runner's measured prove at epoch 2^22) plus ~8 min
-# of setup. The FIRST run measures the sd — it is the `sd` field of the paired-t line
-# in the result comment — and this table should be re-pinned to it then.
+# Wall is 2 x ~125 s per pair (the runner's measured prove at epoch 2^22) plus ~8 min of
+# setup. Read the column the run earned, not the one you want: the script prints an
+# exclusivity line reporting the CPU share of every prove and flagging any that came in
+# under 90% of the batch's best. A flagged batch belongs in the right-hand column.
+#
+# The workload rebuild did tighten this, but not as far as first recorded: a
+# 5-prove baseline put the CV at 0.57%, and its 95% interval was [0.34%, 1.64%] — wide
+# enough that the point estimate was not worth pinning a table to, which is what the
+# 14-prove follow-up then showed. Numbers from before the bump measured a different
+# fixture (block 25368371 as an rkyv ProgramInput) and are not comparable.
 on:
   issue_comment:
     types: [created]
 
 env:
   # The epoch /bench proves this block at, so the tiebreaker resolves the same
   # configuration and not just the same block. Memory picks it: this runner peaks at
-  # ~52 GB here against its >=64 GiB floor. See benchmark-pr.yml's REAL_BLOCK_EPOCH_LOG2.
+  # 44.81 GiB here against its >=64 GiB floor, and 2^23 would take that past 50 GiB
+  # for ~7% of wall. See benchmark-pr.yml's REAL_BLOCK_EPOCH_LOG2.
   ABBA_REAL_EPOCH_LOG2: "22"
 
 concurrency:
@@ -50,8 +61,8 @@ jobs:
       startsWith(github.event.comment.body, '/bench-abba') &&
       contains(fromJSON('["MEMBER","OWNER","COLLABORATOR"]'), github.event.comment.author_association)
     runs-on: [self-hosted, bench]
-    # Hang guardrail, not expected duration: a real-block pair is 2 x 158.8 s = ~5.3 min,
-    # so the default 12 pairs runs ~72 min and the 40-pair clamp ~3.7 hr, plus up to
+    # Hang guardrail, not expected duration: a real-block pair is 2 x 125.17 s = ~4.2 min,
+    # so the default 12 pairs runs ~58 min and the 40-pair clamp ~2.9 hr, plus up to
     # ~30 min of two-sided build on a cold cache.
     timeout-minutes: 360
     steps:
@@ -117,9 +128,9 @@ jobs:
             await github.rest.issues.createComment({
               owner: context.repo.owner, repo: context.repo.repo,
               issue_number: context.issue.number,
-              // A pair is TWO proves at the runner's measured 158.8 s, so ~5.3 min/pair,
-              // plus ~8 min of checkout, two-sided build and fixture fetch.
-              body: `⏳ **ABBA tiebreaker started** on the bench server: ${process.env.PAIRS} pairs of ${process.env.WORKLOAD} — a pair is 2 proves at ~158.8 s, so roughly ${Math.round(8 + Number(process.env.PAIRS) * 5.3)} min. Pass a smaller pair count for a quicker, coarser run. The bench server is occupied until it finishes.`
+              // A pair is TWO proves at the runner's measured 125.17 s, so ~4.2 min/pair,
+              // plus ~8 min of checkout, two-sided build and fixture build.
+              body: `⏳ **ABBA tiebreaker started** on the bench server: ${process.env.PAIRS} pairs of ${process.env.WORKLOAD} — a pair is 2 proves at ~125 s, so roughly ${Math.round(8 + Number(process.env.PAIRS) * 4.2)} min. Pass a smaller pair count for a quicker, coarser run. The bench server is occupied until it finishes.`
             });
 
       - name: Checkout (full history for ref resolution)

.github/workflows/benchmark-gpu.yml

@@ -9,7 +9,7 @@ name: Benchmark GPU (PR)
 # Triggered by a "/bench-gpu [N]" comment on a PR (N = pair count, default 14) or via
 # workflow_dispatch.
 #
-# Workload: the real block (see tooling/ethrex-block-converter/README.md), proven with
+# Workload: the real block (see tooling/ethrex-fixtures/README.md), proven with
 # --continuations at the calibrated epoch size below.
 # Orchestration runs on a GitHub-hosted runner; all GPU work happens on the rented
 # Vast box (provisioned by the template onstart).
@@ -229,11 +229,19 @@ jobs:
           # because vast can't numerically compare the driver_version string server-side.
           MIN_DRIVER: "580"
         run: |
-          # cpu_ram filter is in GB. Floor 48 GB: the real block at epoch 2^22 peaks at
-          # ~36 GB host RSS on the CUDA path (measured, main vintage) — ~25% headroom.
+          # cpu_ram filter is in GB. Floor 64 GB, raised from 48 with the rebuilt
+          # workload: that block peaks at 44.81 GiB (47.0 GB) at epoch 2^22 on the CPU
+          # path, which on a 48 GB box is 98% of RAM -- not headroom to lose to a
+          # rental with a slightly hungrier allocator, it is already over. 64 GB restores the ~28% headroom the
+          # 48 GB floor had for the old block (~36 GB host RSS on the CUDA path,
+          # measured at main vintage) and matches the CPU runner's own floor. It costs
+          # offer availability: fewer boxes qualify, so PRICE_CAP may need a look if
+          # the query starts coming back empty. Peak is set by the epoch size, not the
+          # block, so dropping GPU_REAL_EPOCH_LOG2 to 21 is the other lever (~24 GiB,
+          # +14% wall).
           # Continuation peak is set by the epoch size, not the block, so bigger blocks
-          # don't move it; raising the epoch would (see the calibration tables in
-          # tooling/ethrex-block-converter/README.md).
+          # don't move it; raising the epoch would (see the epoch table in
+          # tooling/ethrex-fixtures/README.md).
           # gpu_frac=1 requires a WHOLE-MACHINE offer (you rent every GPU on the host), so
           # Vast places no other tenant on the box: CPU cores, RAM/memory bandwidth, PCIe,
           # and NVMe are fully dedicated. Without it the "most expensive" sort below lands on
@@ -246,7 +254,7 @@ jobs:
           # at the toolchain sanity gate. `reliability` is the queryable field (the
           # `reliability2` in the response schema is display-only, not filterable).
           # Over-strict just yields no offers, surfaced by the retry loop's "No offer".
-          QUERY="gpu_name=${GPU_NAME} num_gpus=1 gpu_frac=1 cpu_cores_effective>=16 cpu_cores_effective<=32 cpu_ram>=48 disk_space>=64 verified=true rentable=true reliability>=0.95 cuda_max_good>=12.8 dph_total<=${PRICE_CAP}"
+          QUERY="gpu_name=${GPU_NAME} num_gpus=1 gpu_frac=1 cpu_cores_effective>=16 cpu_cores_effective<=32 cpu_ram>=64 disk_space>=64 verified=true rentable=true reliability>=0.95 cuda_max_good>=12.8 dph_total<=${PRICE_CAP}"
           echo "Query: $QUERY (+ client-side driver_version major >= $MIN_DRIVER)"
           # Keep only offers whose driver major >= MIN_DRIVER, then most expensive first
           # (within the price cap). Within the now whole-machine pool, price just tracks
@@ -495,7 +503,7 @@ jobs:
           # That surfaces as the OOM killer reaping a rustc ("signal: 9") or as an
           # allocation failure mid-compile. (Distinct from the toolchain gate's concern
           # above, which is a host that is broken before any load is applied.)
-          # 8 leaves ~6 GB/job on the >=48 GB floor; the build is a one-time per-bench
+          # 8 leaves ~8 GB/job on the >=64 GB floor; the build is a one-time per-bench
           # cost, and the job timeout above has ample room for it.
           REMOTE="set -e; cd /workspace/lambda_vm; \
             command -v python3 >/dev/null || { apt-get update -qq && apt-get install -y -qq python3; }; \