Repository navigation
quest: report the cluster spike (relay per thread, nothing shared) - #7534
Conversation
…r.md Quest-Claim: 98ce36a6deb1b29d
Throwaway: SPIKE_CLUSTER=1 gives each tokio worker its own Cluster and origin, meshed over moq-lite-06 memory sessions. The spike_announce example measures announce delay, frame delay across the hop, and announce table memory. bench/relay.sh gains BENCH_PIN and SPIKE_PERF_STAT, and bench/profile.py SPIKE_PERF_BUFFER. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The spike never merges; its prototype lives in ddd8b04. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The maintainer settled the spike's decision on 2026-11-01: relay-per-thread is planned, on the condition that the worker mesh never re-announces peer routes to peers. Record the condition, the routing-semantics change, the unmeasured cost, and how it relates to the replica spike. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 4 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. CodeRabbit Verify
|
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
- Epic README records the cluster spike. Adds the "Cluster spike (2026-11-01)" section: data-plane table (chat/fanout at 1/4/16 workers, pinned and unpinned), lock wait dropping to zero, CPU and resident-memory deltas, per-hop instruction cost, and the
spike_announcecontrol-plane table showing W-squared announce state and convergence. - Verdict and conditions. Records the maintainer's conditional win: relay-per-thread proceeds only with a worker mesh that never re-announces peer routes, which shrinks announce state to about one route per worker, and notes that this changes cluster routing semantics and is unmeasured.
- Quest deleted and links dropped. Removes
spike-cluster.md(spike reported; prototype atddd8b04never merged) and its bullets from both the epic Required list andlog-adoption.md.
I checked the tree for dangling references and cross-checked the figures against the PR body and the follow-up quest quest/m2/perf/cluster-route-memory.md; they agree (886 KB at 16 workers = 240 routes x ~3.7 KB; per-worker per-broadcast 5.4/11.3/25.3/55.4 KB at 2/4/8/16). Documentation-only, no behavioral surface.
deepseek-v4.1-flash (free via Pullfrog for OSS) | 𝕏
kixelated
left a comment
There was a problem hiding this comment.
Automated review by review (OpenAI)
Reviewed commit: 8ccf8e86052595771dc9c1bcf0d592bafec79ffe.
No actionable bugs found in the three-file quest-only diff. Keeping the prototype out of the merged tree is the simpler, appropriate scope. The report separates the measured full mesh from the unmeasured no-re-announce design and preserves the shared-control-plane replica comparison; external-route propagation remains explicitly a planning question, not an established property. No runtime, public API, or wire change lands here.
Verification: static inspection of the changed quests, related replica plan, cluster session setup, and linked prototype. I did not rerun the benchmarks or tests, independently verify the reported measurements, or validate the proposed replacement mesh.
(Written by OpenAI)
Report the cluster spike after the replica spike and version counter sections that landed on main, drop the now-landed replica spike's "still runs" wording, and remove log adoption's last Required link. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
kixelated
left a comment
There was a problem hiding this comment.
Automated review by review (OpenAI)
Reviewed commit: 8a1bd49
No new actionable issues found. Accounting for the merged replica and version-counter reports, the reconciliation keeps both conditional wins and the unmeasured routing trade-off explicit, and removes the completed spike dependency.
Static GitHub review only; I did not rerun measurements or tests.
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
- Merged
origin/mainand reconciled the epic README with the reports that landed there: the landed version-counter and replica-spike sections are absorbed, and the## Requiredlist drops to Log adoption. - Cross-referenced the no-re-announce condition to the planned per-connection
proxypreference in/quest/m1/cluster-routing/routes.md, and linked the already-plannedcluster-route-memory.mdfollow-up. - Rewrote the spike references in the epic README and
log-adoption.mdto past tense, recording that neither conditional win settles adoption.
The reconciliation is clean: no dangling spike-cluster/spike-replica/version.md references, every linked quest path resolves, no conflict markers, and both cited PRs (#7532, #7533) are merged. Documentation-only, no behavioral surface.
deepseek-v4.1-flash (free via Pullfrog for OSS) | 𝕏

Problem
Claims the cluster spike: measure a relay per worker thread, each with its own
Clusterand origin and nothing shared, clustered over the in-memory transport, against today's shared origin. Its numbers and a recommendation go in the kio channel contention epic.Approach
The prototype is moq-dev/moq@ddd8b04. The next commit removes it, so this PR merges only the epic README update and the quest deletion, as moq-dev/moq#7057 did for its spike.
SPIKE_CLUSTER=1withruntime.workers: each tokio worker builds its ownCluster(origin, cache pool, origin driver) on its thread. The workers link in a full mesh of moq-lite-06memorysessions that publish and subscribe like a dialed cluster peer (Cluster::run_remote_session), so announcements, routes, and groups all cross workers through moq-lite.just bench-profile lockfor fanout and chat at 1, 4, and 16 workers, both arms on the same build in the same session. Two pinned passes, a third for pinned chatbase, and one unpinned pass. The bench gainedSPIKE_PERF_STAT(perf statinstructions and cycles, user and kernel, both core types, over the same 5 s steady window as the lock capture),BENCH_PIN, andSPIKE_PERF_BUFFER.rs/moq-relay/examples/spike_announce.rsmeshes W origin threads the same way to measure what the generator cannot: announce propagation delay, announce table memory (counting allocator), burst convergence, and the frame delay one hop adds.The host stayed loaded (load average 15 to 25, other agents benchmarking). So instructions per delivered frame rank the arms, and wall-clock numbers only corroborate them.
Findings
Full tables are in the README diff. Thousand instructions per delivered frame,
basetocluster(medians of passes):clusterrun measured 0 to 2 ms, againstbase's 2.1 to 3.2 s for chat and 0.67 to 0.77 s for fanout at 16 workers.Findings: the data plane wins where a track fans out widely per worker (chat), and breaks even or loses where it doesn't (fanout). Sharing nothing through today's full mesh then costs announce state and propagation that grow with W squared.
Decisions
Decided (maintainer, 2026-11-01). Does the cluster spike count as a win for
/quest-plan?The epic README records the verdict and its condition, and notes:
The relay-per-thread quest is not written here; it is planned with the maintainer through
/quest-plan(see Suggested follow-ups).Merge with main (2026-11-02)
Merged
origin/main(945aec5a), which had landed the version counter (moq-dev/moq#7532) and replica spike (moq-dev/moq#7533) reports in the same epic, and moq-dev/moq#7648's## Waitingand P2P edits elsewhere. The report still applies: the cluster spike quest was still open onmain, the replica report says to weigh it against this one, and the cluster code still re-announces every learned route with hop chains.spike-cluster.mdnow points to the cluster spike section below it. The verdict's "replica spike still runs" bullet now says it has reported.proxypreference. A worker link with it off is the condition. Nothing about it is decided here.mainhad already dropped its replica spike link, so removing the cluster spike link empties itsRequired. That follows the 2026-10-14 decision ("Log adoption waits on the spikes"). Its Plan now records that neither conditional win settles whether the shared model survives, and that adoption is likely abandoned if relay-per-thread lands.Choices made without asking
[cache]config, unbounded in the bench. Per-worker clusters keep stats disabled; the bench config enables none.runtime.pin) for the instruction counts, plus one unpinned pass for the relay's default.basechat (three refused runs).basechat: its lock capture failed three times (perf "nonalternating switch records"). Its CPU and instructions come from acpu-mode pass, so it has no lock-wait number.SPIKE_CLUSTER, notMOQ_SPIKE_CLUSTER, because the relay refuses unknownMOQ_variables.Suggested follow-ups
/quest-planper the maintainer's 2026-11-01 decision above. It is not planned yet; the planning should weigh the replica spike's per-track replicas against it, and decide whether Log adoption waits on it.uring-bench-followupsnotes the startup artifact.)bench-profile lockrobustness.Review
Codex (
quest review), gpt-6.1-sol, medium effort, round 1 on head8a1bd49cagainstorigin/main945aec5a: no findings. The online reviews on8ccf8e86(Pullfrog, OpenAI) reported none either. On8a1bd49c,quest check --base origin/main(dev shell) andjust check origin/mainboth passed.🤖 Generated with Claude Code
(Written by Claude Opus 5.5)