Characterize native x86 and ARM custody hosts

[metaphorics]

Question

Which native x86-64 and ARM64 machines, CPU features, physical-core masks, storage devices, governors, firmware, toolchains, and isolation controls will produce comparable custody?

Blocked by

• None

[metaphorics]

Custody-host characterization — corrected status

Status: BLOCKED. Do not close this ticket. The current machine supplies a useful x86-64 candidate, but the evidence does not yet establish complete x86 custody and identifies no native ARM64 custody host. The two architectures therefore do not yet have symmetric, comparable custody.

Current x86-64 machine: directly observed facts

• System: Dell Inc. Precision 7920 Tower.
• CPU: Intel Xeon Gold 6138 @ 2.00 GHz, native x86-64. CPUs 0-79 are online. Package 0 exposes 0-19,40-59; package 1 exposes 20-39,60-79. This is 2 sockets × 20 physical cores × 2 SMT threads = 80 logical CPUs. Thread-sibling examples are 0,40 and 20,60.
• Instruction features reported by the kernel: SSE4.1/4.2, AES, PCLMULQDQ, FMA, BMI1/2, AVX, AVX2, and AVX-512 F/DQ/CD/BW/VL. Per the campaign taxonomy, AVX2 is the required x86 production feature; AVX-512 remains diagnostic and cannot substitute for the required cells.
• Historical affinity contract: docs/benchmarks/data/end-to-end-sync/avx2-merkle-custody-v1.json records taskset -c 0-31. Current topology proves that mask selects 32 distinct physical cores and no SMT siblings. It is not NUMA-balanced: node 0 contributes CPUs 0-19 and node 1 contributes 20-31. If the campaign retains this mask, Candidate, immediate control, and Core must use the exact same mask and the same declared NUMA memory policy. The present evidence does not prove the mask is optimal or portable to ARM.
• Memory visible to Linux: 791180784 kB (about 754.5 GiB). No cited source proves DDR generation, DIMM layout, or ECC state, so those properties remain uncharacterized.
• Governor and turbo: all discovered cpufreq policy governors read powersave; the driver is active intel_pstate; no_turbo=0; policy 0 permits 1.0–3.7 GHz. These are dynamic settings and must be captured immediately around every custody pair. powersave under active Intel P-state must not be described as a fixed clock.
• Firmware: Dell BIOS 2.46.0, dated 03/13/2025; CPU microcode 0x2007006.
• Storage currently backing /home: /home is rpool/USERDATA/home_eq3uuw on ZFS. zpool status -P rpool maps rpool to partition 4 of a T-FORCE TM8FFE004T NVMe; that device reports firmware 1.c.P.45. A Samsung MZVLB512HAJQ-000L7 NVMe with firmware 5L2QEXA7 is also present, but it does not back rpool. /tmp is tmpfs. This is only a host inventory: the historical custody JSON leaves $DATA_DIR, $CORPUS, $CORE_DATADIR, and $BENCH_RESULTS unresolved, so it does not prove which device held the timed chainstate, block corpus, or Core datadir.
• Current toolchain in the authoritative worktree: rust-toolchain.toml pins Rust 1.95.0; direct probes report rustc 1.95.0 (x86_64-unknown-linux-gnu, LLVM 22.1.2) and cargo 1.95.0. Current PATH reports GCC 16.0.1 20260322 (experimental) and GNU ld 2.47.20260726. /proc/version separately says the running kernel was built with GCC 15.2.0 and ld 2.46; those kernel-build versions are not the current application toolchain and must not be substituted for it. The historical artifact’s binary hashes do not record which C compiler/linker built its native dependencies.
• Isolation actually evidenced: the historical artifact declares the 0-31 affinity mask, 30-second cooldowns, and a rotated Candidate/Core order. The current kernel command line has no isolcpus, nohz_full, or rcu_nocbs, and the root cgroup exposes 0-79. No cited source establishes a dedicated or “multi-tenant” host, IRQ isolation, NUMA memory binding, or current idle-host state.

Benchmark numbers are not host-characterization evidence

Remove the recalled 157.8s and 190.7s figures: they do not occur in the cited custody artifact and are stale/incomparable to this ticket. The artifact’s actual historical medians are 49.35619607393164s for bitcoin-rs and 64.91389806405641s for Core, but the campaign taxonomy explicitly marks that panel provisional: it is tied to bitcoin-rs commit 65bae8dab0cbab41f2ef5d7cbc2cb906b2105643, not the stated current tree, and its body-source/persistence contract is not yet strict. Those timings cannot prove today’s host isolation and cannot close this ticket.

ARM64 evidence and exact blocker

No native ARM64 host was identified in the supplied evidence. The SSH capability registry has no configured hosts, there is no user ~/.ssh/config, and known_hosts contains only GitHub records. That does not prove that no ARM host is reachable; it proves only that no endpoint or allocation was supplied or discoverable through those sources.

The taxonomy requires native AArch64 production measurements, with runtime-dispatched NEON/SHA2 where supported and a forced-feature-disabled scalar parity/fallback path. It separately says the exact ARM64 feature floor remains unspecified. Therefore SHA2 support must not be asserted as an already-frozen admission requirement.

Missing prerequisite for the next research pass: provide or identify a native AArch64 host, then record its machine/CPU model, online CPUs, packages/clusters/SMT topology, physical-core mask, NUMA topology and memory policy, reported NEON/SHA2 features, governor/boost state, RAM facts, exact timed storage device and mount chain, BIOS/UEFI plus CPU and storage firmware, active Rust/C/linker toolchains, and isolation controls. Freeze the ARM feature floor and use the same native host, exact mask, storage/cache/durability contract, validation posture, fresh-state policy, rotation, cooldown, and idle-host checks for each Candidate/Core pair.

Until that pass also binds the x86 benchmark variables to actual devices and freezes its NUMA/isolation policy, the x86 host is only partially characterized and the x86/ARM custody matrix remains open.

[metaphorics]

Custody progress: x86-64 candidate characterized; native ARM64 remains blocked

Observed x86-64 candidate

Field	Observed value
System	Dell Precision 7920 Tower, Linux 7.0.0-28-generic on Ubuntu 26.04 LTS
CPU	Two Intel Xeon Gold 6138 packages, 20 physical cores per package, two threads per core, 80 logical CPUs; microcode 0x2007006
Features	AVX2, AVX-512F/DQ/CD/BW/VL, BMI1/2, FMA, AES, and PCLMULQDQ
NUMA	Node 0 owns CPUs 0-19,40-59; node 1 owns 20-39,60-79; total memory is 791,180,784 kB
Historical affinity	taskset -c 0-31 selects 32 physical cores with no SMT siblings, but spans both NUMA nodes asymmetrically: 20 cores on node 0 and 12 on node 1. This is a historical load-control mask, not yet the final custody mask
Storage	/home is ZFS on rpool, backed by the 4 TB T-FORCE TM8FFE004T NVMe device (firmware 1.c.P.45); /tmp is tmpfs; a secondary Samsung NVMe device is present but is not the /home backing device
Power and isolation	intel_pstate is active, the governor reports powersave, turbo is enabled, and the configured range is 1.0-3.7 GHz; the kernel command line has no isolcpus, nohz_full, or rcu_nocbs; the effective root cpuset is 0-79
Current repository toolchain	Rust 1.95.0; historical benchmark artifacts bind commit and binary hashes, but do not fully bind the C/C++ compiler, linker, native library flags, firmware state, or final data path required for new custody

Sources include /proc/cpuinfo, /proc/meminfo, /proc/cmdline, /proc/mounts, /sys/devices/system/{cpu,node}, /sys/class/block/nvme*/device, rust-toolchain.toml, and the existing benchmark custody JSON.

Missing x86-64 custody inputs

• Final CPU/NUMA binding and memory policy.
• A dedicated, verified data path plus filesystem, ZFS dataset properties, free-space floor, and I/O scheduler/queue settings.
• Exact Core 31.1 and bitcoin-rs compiler, linker, native-library, feature, and binary hashes.
• Pretrial host-load rejection rules and machine-readable capture of governor, turbo, thermals, frequency, memory pressure, and competing processes.
• Any privileged DIMM/ECC and NVMe health facts selected as required custody fields.

Native ARM64 blocker

No native ARM64 performance host has been supplied or identified in the campaign configuration. Public GitHub-hosted ARM64 runners are native, but their 4 CPUs, 16 GB RAM, and 14 GB SSD cannot hold the modern cumulative corpus plus the required fresh Core and three bitcoin-rs backend stores. Cross-compilation, QEMU, and those undersized runners can prove portability only; they cannot satisfy native ARM64 performance custody.

This ticket stays open until a suitable native ARM64 host is allocated and both architectures have complete, machine-captured custody records.