Repository navigation
feat(coordinator): feed the CUDA miner from a quip-screen sidecar - #38
rdyplayerB wants to merge 2 commits into
Conversation
With QUIP_SCREEN_BIN set, the feeder writes the snapshot topology to a spec file, runs `quip-screen serve`, sends it each round's prev hash and identity, and queues the salts it keeps, deepest first per generation. cuda* miners are topped up from that queue; the job is still derived with derive_pow_job, so validation, stash and submission are unchanged. An empty queue stages nothing unless QUIP_SCREEN_FALLBACK=1; a dead sidecar falls back to counter salts. Unset: no behaviour change.
🤖 Augment PR SummarySummary: Adds an optional Changes:
QUIP_SCREEN_ARGS is forwarded to the sidecar.
🤖 Was this summary useful? React with 👍 or 👎 |
| "nodes": snap.nodes, | ||
| "edges": snap.edges.iter().map(|&(u, v)| [u, v]).collect::<Vec<_>>(), | ||
| "allowed_h_milli": snap.allowed_h_milli, | ||
| "allowed_j_milli": snap.allowed_j_milli, |
There was a problem hiding this comment.
crates/quip-coordinator/src/screen.rs:164 omits allowed_spin_milli, even though it is part of the topology-spec schema and canonical topology hash. For a non-default spin set, quip-screen will default to ±1000 and screen a different solution domain than the coordinator's snapshot.
Severity: medium
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| "quip-screen-{}.json", | ||
| hex(snap.topology_hash.get(..8).unwrap_or(&snap.topology_hash)) | ||
| )); | ||
| if let Err(e) = std::fs::write(&spec, spec_json(snap)) { |
There was a problem hiding this comment.
crates/quip-coordinator/src/screen.rs:197 writes to a predictable, topology-derived filename in the shared temp directory with fs::write, which follows existing symlinks. A local user can pre-create that known path as a symlink and cause the coordinator service account to truncate and overwrite another file it can write.
Severity: high
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
In a long round the screened-salt queue reached its 20,000 cap and then dropped every new salt, including ones deeper than those waiting. At the cap it now keeps its deepest half and admits the new salt.
What
With
QUIP_SCREEN_BINset, the feeder runsquip-screen serve(QuipNetwork/quip-miner-cuda#1) and givescuda*miners the deepest screened salts instead of counter salts.screen.rs: writes the snapshot topology to$TMPDIR/quip-screen-<hash>.json, starts the sidecar with--spec, sendsR <generation> <prev hash> <identity>on each round change, and queuesK <generation> <salt> <energy>lines, deepest first, per generation.runtime.rs: when topping up acuda*miner, pop the deepest queued salt of the current generation and derive the job withderive_pow_job. Validation, stash and submission are unchanged.QUIP_SCREEN_FALLBACK=1tops it up with counter salts instead.QUIP_SCREEN_ARGSpasses probe settings (--reads-log2,--sweeps,serve --keep-per-s).COORDINATOR.md: new "Probe screen (optional)" subsection under the feeder.QUIP_SCREEN_BIN: no change in behaviour.Checks
cargo fmt --all --check,cargo clippy -p quip-coordinator --all-targets -- -D warnings.cargo test -p quip-coordinator: all pass, including 4 new tests (queue order and generation filtering, reset, hex round trip, sidecar line parsing).Related: #36 and #37, two
driveproblems found while measuring the screen.