Graviton5 native RandomX calibration

Measured 2026-09-09 on the separately provisioned c9g.4xlarge in us-west-2. CPU MIDR 0x410fd841, Rust1.97.1, native GNU ARM build of pinned RandomX2.0.1, explicit algorithm v2, full dataset mode. These are calibration observations, not a formal wall-clock security bound or in-enclave attestation evidence.

Both used the same release executable, SHA256 in binary-sha256.txt. The seven-worker container was independently observed with 16 available CPUs, affinity 0-15 and approximately 699.5% CPU utilization. Each worker holds a separate VM and all workers share one dataset. No other benchmark ran in parallel.

At 43,768,124 iterations per segment, the measured solo rate predicts seven days for seven serial segments. The slowest parallel worker predicts 25.139 hours to generate a puzzle, including dataset setup: a practical speedup of approximately 6.685×. Consequently a fixed daily epoch can have a gap while its successor finishes; it must refuse requests rather than extend the expired key. Faster hardware and timing variance may shorten recovery.

An earlier 2,000-hash seven-worker exploratory run is excluded: the Nitro allocator had left only four host CPUs online, making it an oversubscribed host benchmark. graviton5-calibrate.sh verified no enclave existed, saved the allocator config, returned the reserved cores to the host, ran the full tests, then restored the exact original CPU pool. allocator-before.yaml and restored-cpu-pool.txt record that restoration; the script compared the post-run allocator configuration byte-for-byte.

The calibration source snapshot was preserved before further edits at remote calibration-20260909T201903Z/source-snapshot.tar and local gitignored .local/graviton5-calibration-source.tar, SHA256 6967b24e0cf0c200d671b6610116b4dd64fab11d505e615fe78f018a5fdb2912. This snapshot predates the production commit and is not a published production measurement. Reproduce the measured production EIF from its eventual exact source commit and pinned image.