diff --git a/docs/bench-log.md b/docs/bench-log.md index 5713bfd0c..09c4cb537 100644 --- a/docs/bench-log.md +++ b/docs/bench-log.md @@ -853,3 +853,42 @@ PC predicted a different epoch, and the 57ac pack was simply the previous epoch' worker with jobs queued and no job done for 60 s), workers emit `need ` before the error. Not measured here: the swap time of the forced prepare on the PC; the OpenCL run's "2 jobs in 154 s" were the two jobs before the first mismatch and are not a rate. + +## 4 October 2026, shard proving on the RTX 5090 (skeleton: the GPU column fills from the first `shard-benchmark` job) + +Machine: the project lead's PC 2 (RTX 5090, 32,607 MiB; WSL2 Ubuntu 24.04, SP1 v6.8.1 with the cuda feature, the toolchain of the +4 October morning run in `~/igneum-prove`), the Igneum Miner app (machine id 1ccfe586) stopping its miners for the +run. Delivered as the signed job `shard-benchmark` (`app/igneum-app/src/jobrun.rs`, `packaging/ota/publish-jobs.sh`), +which runs `prove-shard.sh block-338-shard1 "block-341-shards2 block-344-shards4"` and reports every RESULT line to the +intake as `job--1ccfe586` (`node tools/jobs.mjs `). The Mac CPU column is the 4 October entry above +("proving: devnet v4 shards"); the Mac proved only the 200-pgas test cut, so its shard rows at `S_p` are the +executor alone. `S_p` = 7,500,000 pgas provisional; the fixtures carry 6.75 M pgas per shard. + +| Stage | Apple M5 Max CPU (4 October, loaded) | RTX 5090 (job id, UTC) | +|---|---|---| +| shard at `S_p` (block-338-shard1, 6.75 M pgas): execute | 60.0 M cycles, 9 per pgas, 6.9 s (block-344 shard 0, the same size) | | +| shard at `S_p`: core proof (prove s, bytes, verify s) | not run at `S_p` (200-pgas shard: 83.1 s, 7,310,257 B, 0.368 s) | | +| shard at `S_p`: compressed proof (prove s, bytes, verify s) | not run at `S_p` (200-pgas shard: 272.3 s, 1,272,897 B, 0.075 s) | | +| two-shard block (block-341-shards2): compressed proof per shard | not run | | +| two-shard block: aggregation (prove s, bytes, verify s) | not run (three 200-pgas shards: 244.5 s, 1,272,909 B, 0.084 s) | | +| two-shard block: end to end, first shard proof to the verified block proof | not run (three 200-pgas shards: 1,139 s) | | +| four-shard block (block-344-shards4, near `B_p`): compressed proof per shard | not run | | +| four-shard block: aggregation (prove s, bytes, verify s) | not run (aggregator statement 1.66 M cycles) | | +| four-shard block: end to end | not run | | +| setup (one per program id) | 39.4 to 60.6 s (client plus two key setups) | | +| GPU idle wait before the run, package download and extract, build (incremental) | | | + +Reading: pending the run. What it decides: the first `S_p` point (the shard stage time on the card against the +20 to 60 s proof lag of the litepaper), whether the P20 Drop fix holds on the GPU path (exit 0, no abort after the +results), and the gap before the first compressed stage (the ten silent minutes of the v0 run). + +## 4 October 2026, first outside machine on the devnet: an Apple silicon laptop through the Igneum Miner app + +A friend of the project installed Igneum Miner 0.3.1 from the DMG on an Apple silicon laptop (machine id `3a9bf309`, no +toolchain, no instructions beyond the five steps in the morning summary: drag to Applications, Open Anyway in Privacy & +Security once, Get started, Make me an address, Start mining). Node synced from the seed and the LAN-less path (the seed +at the public address first), the Metal worker reported ready and the first block was accepted within the first minutes; +after 7 minutes: 33 accepted blocks, 0 rejected, 21.0 MH/s average (24.3 MH/s at the moment of the report), CPU re-check +OK on every share. Node 1 counted 7 peers with the laptop connected. The log intake received its uploads every minute +under the per-install id, so the machine is observable without any contact from its owner. Observed by the team; the +machine is not ours, so this is the first row that is not "the project's own hardware". diff --git a/site/bench.html b/site/bench.html index 6c1e9a061..489a83fda 100644 --- a/site/bench.html +++ b/site/bench.html @@ -69,7 +69,7 @@ footer{border-top:1px solid var(--line);padding-block:32px 48px;font-size:13px;c

Engineering log

Every measurement the project has made, newest at the bottom, written by the people and agents who ran it, with the commands and hardware. Prototype numbers are not mining numbers and say so.

- +

Igneum bench log

Append-only. Every number here was measured on the machine named, on the date given.

2026-10-03 proto-metal / igneum-bench, first run

@@ -261,7 +261,13 @@ footer{border-top:1px solid var(--line);padding-block:32px 48px;font-size:13px;c
ChangeWhereMeasured after
Notifications only enqueue; a drain loop handles them in bounded batches; block flush, colour marking and certificate work on separate timers, none waits on anotherobserver.mjsqueue_depth 0
Mergesets taken from each notification's verbose data (bounded cache of 4,000); getBlock only on a miss, four in flightobserver.mjs0 RPC fetch failures in the first 5 min
live_state.observer_lag_s (now minus newest stored header time) and queue_depth; served by /api/live; the page shows "observer N s behind" past 30 s instead of "waiting for the first block"observer.mjs, site/api/live.mjs, site/live.htmllag 0.7 s at 13:27 UTC
blocks_per_minute and blocks_60s bucketed by the block's own timestamp, reseeded from the table on startobserver.mjs13:18 = 76, 13:19 = 63; max in the hour 110
Self-check: no blockAdded for 60 s while the node's block_count advances resubscribes; two failed attempts exit 2observer.mjsnot yet triggered
tools/observer/run.sh: restart loop, same env and log (/tmp/igneum-devnet/observer-mjs-v4.out)newrunning since 13:26 UTC

Open: the gap itself. Zero blocks for 78 minutes followed by every missed block arriving with its original header time is also what a stalled observer node delivering its own catch-up looks like; the lag metric now makes either case visible on the page within 30 s, and the self-check covers the dead-subscription case. Node logs for 11:57 to 13:18 UTC would settle which it was.

4 October 2026, PC 2 at the 14:20 boundary: a worker stuck on the previous epoch (root cause from the uploads)

-

Run win-1ccfe586-20261004-132055 (the Igneum Miner app, package 0.3.0 workers). Sequence from the node and miner uploads: the app reinstalled and its node restarted at 13:20:29 UTC in IBD from DAA 17,881, inside epoch 4 (seed 57ac7663...); the app exported packs\devnet from that node's template at once, so both workers started on 57ac. The boundary at DAA 18,000 passed about a minute later. The CUDA miner's first templates still carried next_epoch_seed c23e65dd... within lead: PREPARE sent at 14:20:57, prepared 0.9 s later (NVRTC 151 ms, cache 68, dataset 113, self-test 511 ms), switched to the prepared pair at 14:21:28, then 60 MH/s with 8 identities and 101 accepted blocks in 271 s. The OpenCL worker reported ready 43 s after the CUDA one (14:21:39); by then every template was on c23e as the current pair and no next epoch was within lead, so the miner never sent a prepare, and the worker answered 514 jobs in a row with epoch seed mismatch (one every 0.5 s, the miner's error back-off) for the rest of the run. The message text "holds prepared epoch 57ac..." is host.c's wording for a pack read at run time, which is why the stuck worker looked like a wrong prediction: PC 2's node announced the same next epoch (c23e) as the chain. No node on this PC predicted a different epoch, and the 57ac pack was simply the previous epoch's. Fixes: devnet-v4 miner 3bfe346f (prepare the current pair after a need line or three mismatches; exit 42 without prepare support; restart a ready worker with jobs queued and no job done for 60 s), workers emit need <epoch> <day> before the error. Not measured here: the swap time of the forced prepare on the RTX 5090 machine; the OpenCL run's "2 jobs in 154 s" were the two jobs before the first mismatch and are not a rate.

+

Run win-1ccfe586-20261004-132055 (the Igneum Miner app, package 0.3.0 workers). Sequence from the node and miner uploads: the app reinstalled and its node restarted at 13:20:29 UTC in IBD from DAA 17,881, inside epoch 4 (seed 57ac7663...); the app exported packs\devnet from that node's template at once, so both workers started on 57ac. The boundary at DAA 18,000 passed about a minute later. The CUDA miner's first templates still carried next_epoch_seed c23e65dd... within lead: PREPARE sent at 14:20:57, prepared 0.9 s later (NVRTC 151 ms, cache 68, dataset 113, self-test 511 ms), switched to the prepared pair at 14:21:28, then 60 MH/s with 8 identities and 101 accepted blocks in 271 s. The OpenCL worker reported ready 43 s after the CUDA one (14:21:39); by then every template was on c23e as the current pair and no next epoch was within lead, so the miner never sent a prepare, and the worker answered 514 jobs in a row with epoch seed mismatch (one every 0.5 s, the miner's error back-off) for the rest of the run. The message text "holds prepared epoch 57ac..." is host.c's wording for a pack read at run time, which is why the stuck worker looked like a wrong prediction: PC 2's node announced the same next epoch (c23e) as the chain. No node on this PC predicted a different epoch, and the 57ac pack was simply the previous epoch's. Fixes: devnet-v4 miner 3bfe346f (prepare the current pair after a need line or three mismatches; exit 42 without prepare support; restart a ready worker with jobs queued and no job done for 60 s), workers emit need <epoch> <day> before the error. Not measured here: the swap time of the forced prepare on the RTX 5090 machine; the OpenCL run's "2 jobs in 154 s" were the two jobs before the first mismatch and are not a rate.

+

4 October 2026, shard proving on the RTX 5090 (skeleton: the GPU column fills from the first shard-benchmark job)

+

Machine: the maintainers' PC 2 (RTX 5090, 32,607 MiB; WSL2 Ubuntu 24.04, SP1 v6.8.1 with the cuda feature, the toolchain of the 4 October morning run in ~/igneum-prove), the Igneum Miner app (machine id 1ccfe586) stopping its miners for the run. Delivered as the signed job shard-benchmark (app/igneum-app/src/jobrun.rs, packaging/ota/publish-jobs.sh), which runs prove-shard.sh block-338-shard1 "block-341-shards2 block-344-shards4" and reports every RESULT line to the intake as job-<id>-1ccfe586 (node tools/jobs.mjs <id>). The Mac CPU column is the 4 October entry above ("proving: devnet v4 shards"); the Apple M5 Max proved only the 200-pgas test cut, so its shard rows at S_p are the executor alone. S_p = 7,500,000 pgas provisional; the fixtures carry 6.75 M pgas per shard.

+
StageApple M5 Max CPU (4 October, loaded)RTX 5090 (job id, UTC)
shard at S_p (block-338-shard1, 6.75 M pgas): execute60.0 M cycles, 9 per pgas, 6.9 s (block-344 shard 0, the same size)
shard at S_p: core proof (prove s, bytes, verify s)not run at S_p (200-pgas shard: 83.1 s, 7,310,257 B, 0.368 s)
shard at S_p: compressed proof (prove s, bytes, verify s)not run at S_p (200-pgas shard: 272.3 s, 1,272,897 B, 0.075 s)
two-shard block (block-341-shards2): compressed proof per shardnot run
two-shard block: aggregation (prove s, bytes, verify s)not run (three 200-pgas shards: 244.5 s, 1,272,909 B, 0.084 s)
two-shard block: end to end, first shard proof to the verified block proofnot run (three 200-pgas shards: 1,139 s)
four-shard block (block-344-shards4, near B_p): compressed proof per shardnot run
four-shard block: aggregation (prove s, bytes, verify s)not run (aggregator statement 1.66 M cycles)
four-shard block: end to endnot run
setup (one per program id)39.4 to 60.6 s (client plus two key setups)
GPU idle wait before the run, package download and extract, build (incremental)
+

Reading: pending the run. What it decides: the first S_p point (the shard stage time on the card against the 20 to 60 s proof lag of the litepaper), whether the P20 Drop fix holds on the GPU path (exit 0, no abort after the results), and the gap before the first compressed stage (the ten silent minutes of the v0 run).

+

4 October 2026, first outside machine on the devnet: an Apple silicon laptop through the Igneum Miner app

+

A friend of the project installed Igneum Miner 0.3.1 from the DMG on an Apple silicon laptop (machine id 3a9bf309, no toolchain, no instructions beyond the five steps in the morning summary: drag to Applications, Open Anyway in Privacy & Security once, Get started, Make me an address, Start mining). Node synced from the seed and the LAN-less path (the seed at the public address first), the Metal worker reported ready and the first block was accepted within the first minutes; after 7 minutes: 33 accepted blocks, 0 rejected, 21.0 MH/s average (24.3 MH/s at the moment of the report), CPU re-check OK on every share. Node 1 counted 7 peers with the laptop connected. The log intake received its uploads every minute under the per-install id, so the machine is observable without any contact from its owner. Observed by the team; the machine is not ours, so this is the first row that is not "the project's own hardware".

diff --git a/site/build.mjs b/site/build.mjs index 023147efb..bc62d329e 100644 --- a/site/build.mjs +++ b/site/build.mjs @@ -180,6 +180,7 @@ if (existsSync(join(docs, 'bench-log.md'))) { ['First hourly program swap on the live devnet', 'First live hourly swap: no pause on Mac, NVIDIA or AMD'], ['First finality lock on the live devnet', 'First live finality lock: 77.4% of weight, 17 voters'], ['First machine on the Igneum Miner app', 'First machine on the one-click app: a 5090 at 118 MH/s'], + ['First outside machine on the devnet', 'First outside machine: a friend\'s Mac mining through the app'], ['Devnet v4 cut-over', 'Devnet v4 live: generator v2, two-thirds floor, fresh chain'], ]; function shortTitle(t) { diff --git a/site/journey.json b/site/journey.json index 9de3049f2..0a8f01f07 100644 --- a/site/journey.json +++ b/site/journey.json @@ -50,6 +50,16 @@ } ], "log": [ + { + "date": "2026-10-04", + "text": "Shard proving on the RTX 5090", + "short": "Shard proving on the RTX 5090" + }, + { + "date": "2026-10-04", + "text": "First outside machine on the devnet: an Apple silicon laptop through the Igneum Miner app", + "short": "First outside machine: a friend's Mac mining through the app" + }, { "date": "2026-10-04", "text": "One-click Windows workers: what the Apple M5 Max could measure", @@ -239,16 +249,6 @@ "date": "2026-10-03", "text": "Fuzzing: 10,200 random programs, 1.3 million hashes, zero GPU to CPU mismatches on Apple silicon.", "short": "Fuzzing: 1.3 million hashes, zero GPU to CPU mismatches" - }, - { - "date": "2026-10-03", - "text": "Second hostile review of the finality rule. Two fatal flaws found and fixed. Rule version 2 published in the design doc.", - "short": "Second hostile review: two fatal flaws found and fixed" - }, - { - "date": "2026-10-03", - "text": "First prototype of the random-program lottery hash ran on an Apple M5 Max. GPU and CPU agreed bit for bit.", - "short": "First prototype of the lottery hash on Apple silicon" } ] }