metrics: stale work is the batch in flight at cancellation, not the whole search #15

grenade · 2026-09-03T11:23:55Z

grenade commented

2026-09-03 11:23:55 +00:00

Correction to #14, found on the first hour of live data.

miner_stale_hashes_total was recorded in the QUIC loop for every result whose job id no longer matched the current one. That is every cancelled search, because a worker interrupted by a new job reports the whole search under the old id. On benjy it flagged 18.3 G of 24.7 G hashes as stale, 74 percent, which is the loop's notion of a stale result and not wasted work: those hashes were done while the job was current.

The wasted work is the batch that completes after the job was superseded, at most one per job switch per worker. That is now recorded in the engine at the cancellation check, per device and kernel, and the loop-level accounting is gone. Expected value is about one batch per job, so with 1M batches at 144 MH/s roughly 7 ms of work per job switch. This is the number #6 trades against batch size.

Label change: miner_stale_hashes_total{engine} becomes miner_stale_hashes_total{device, kernel}. The rule quantus:stale_hash_fraction:rate1h sums by instance and is unaffected.

clippy, fmt and tests clean. The bench workflow runs on this PR since engine-gpu changed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CBgs2nSi4H2mdh8kD8vMX5

Correction to #14, found on the first hour of live data. `miner_stale_hashes_total` was recorded in the QUIC loop for every result whose job id no longer matched the current one. That is every cancelled search, because a worker interrupted by a new job reports the whole search under the old id. On benjy it flagged 18.3 G of 24.7 G hashes as stale, 74 percent, which is the loop's notion of a stale *result* and not wasted work: those hashes were done while the job was current. The wasted work is the batch that completes after the job was superseded, at most one per job switch per worker. That is now recorded in the engine at the cancellation check, per device and kernel, and the loop-level accounting is gone. Expected value is about one batch per job, so with 1M batches at 144 MH/s roughly 7 ms of work per job switch. This is the number #6 trades against batch size. Label change: `miner_stale_hashes_total{engine}` becomes `miner_stale_hashes_total{device, kernel}`. The rule `quantus:stale_hash_fraction:rate1h` sums by instance and is unaffected. clippy, fmt and tests clean. The bench workflow runs on this PR since engine-gpu changed. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01CBgs2nSi4H2mdh8kD8vMX5

grenade added 1 commit 2026-09-03 11:23:56 +00:00

metrics: stale work is the batch in flight at cancellation, not the whole search

ci / fmt (pull_request) Successful in 21s

Details

bench / build (pull_request) Successful in 1m1s

Details

ci / clippy (pull_request) Successful in 1m55s

Details

ci / doc (pull_request) Successful in 1m55s

Details

bench / measure (pull_request) Successful in 2m56s

Details

ci / test (pull_request) Successful in 6m35s

Details

20749c622b

miner_stale_hashes_total was recorded in the QUIC loop for every result whose
job id no longer matched, which is every cancelled search: 74% of all hashes
on benjy flagged as stale on the first hour of data. That is the loop's
notion of a stale *result*, not wasted work; the hashes were done while the
job was current.

The wasted work is the batch that completes after the job was superseded.
Record that in the engine at the cancellation check, per device and kernel,
and drop the loop-level accounting. Expect one batch per job switch.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CBgs2nSi4H2mdh8kD8vMX5

grenade referenced this pull request

2026-09-03 11:24:23 +00:00

Continuous performance telemetry: attribute production hashrate to builds #9

gitea-actionsbot commented

2026-09-03 11:28:32 +00:00

quantus-bench `20749c622b` on benjy.hanzalova.internal

worker	median MH/s	spread	windows
0	143.99	0.2%	144.1, 143.9, 144.0, 143.9, 144.1

total median: 143.99 MH/s (batch 1000000, 5 x 30s, engine gpu-wgpu)

gpu 0 NVIDIA GeForce RTX 4090: driver 580.173.02, limit 250 W, draw 250 W, sm 1230 MHz, 53 C
parity: OK (25/25 jobs found solutions, all verified against CPU)
--- resume miner ---
active

## quantus-bench 20749c622b5634d478f3a27722a84b9ed86f907f on benjy.hanzalova.internal | worker | median MH/s | spread | windows | | --- | --- | --- | --- | | 0 | 143.99 | 0.2% | 144.1, 143.9, 144.0, 143.9, 144.1 | total median: **143.99 MH/s** (batch 1000000, 5 x 30s, engine gpu-wgpu) - gpu 0 NVIDIA GeForce RTX 4090: driver 580.173.02, limit 250 W, draw 250 W, sm 1230 MHz, 53 C - parity: OK (25/25 jobs found solutions, all verified against CPU) --- resume miner --- active

grenade merged commit 48ab3933ba into main

2026-09-03 11:28:44 +00:00

grenade deleted branch metrics/stale-semantics

2026-09-03 11:28:44 +00:00

grenade referenced this issue from a commit

2026-09-03 11:28:46 +00:00

Merge pull request 'metrics: stale work is the batch in flight at cancellation, not the whole search' (#15) from metrics/stale-semantics into main

grenade referenced this pull request

2026-09-03 15:23:12 +00:00

Continuous performance telemetry: attribute production hashrate to builds #9

Sign in to join this conversation.