Document Dragon transport, persistent execution and timing - #49
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: NVIDIA/cuPhoton/.coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
Included review availability: Your plan provides up to 12 included reviews per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe PR adds a Dragon transport and coordination guide. It describes execution paths, transport and queue behavior, benchmark measurements, and measurement boundaries. The README and XPOIS documentation link to the guide. ChangesDragon documentation
Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to The guide describes behavior present in the baseline, and both documentation entry points lead to it. No concrete user-facing or operational risk from this documentation change remains. 🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
Comment |
7fea49f to
b8324d0
Compare
tpn
changed the title
melo-gonzo
left a comment
melo-gonzo
left a comment
There was a problem hiding this comment.
Approving with fixes, and a merge-order request: land this after #50, #54, and #56, or mark the sections that depend on them. The transport framing is right: cuPhoton reads and sets no Dragon transport variable or launcher flag (the only DRAGON_ names in src are the descriptor constants in xpois/dragon.py), so "transport selection belongs to the Dragon launcher" is the correct statement, and the specific env names and -t/-o flags are Dragon 0.14 launcher knowledge rather than repository behavior, which the guide says. Queue placement matches main: one policy-free result queue at the coordinator and a per-worker Policy with host placement and gpu_affinity; the snippet with a placed command queue is generic Dragon usage, fine as an illustration. Persistent execution as merged (lazy per-shard DeviceWorkerContext, one result put per worker, hashed descriptors with the 96 KiB guard) is described correctly. Links and the docs index entry resolve. The ci-required FAILURE is a superseded cancelled run; the live run is green.
|
@coderabbitai review |
✅ Action performedReview finished.
|
Explain native HSTA TCP launches and consumer-local command queues. Separate control latency from pipeline throughput and describe the static shard executor already available in cuPhoton. Signed-off-by: Trent Nelson <trentn@nvidia.com>
Signed-off-by: Trent Nelson <trentn@nvidia.com>
Distinguish single-pass execution from the persistent executor stack. Document current timing and lifecycle boundaries and the 256-GPU follow-up without extending its qualification to newer product code. Signed-off-by: Trent Nelson <trentn@nvidia.com>
Signed-off-by: Trent Nelson <trentn@nvidia.com>
Signed-off-by: Trent Nelson <trentn@nvidia.com>
|
@coderabbitai review |
1a4c8c2 to
3195ddc
Compare
✅ Action performedReview finished.
|
2 participants
Dragon transport choices, queue placement and timing need to be interpreted in the context of the executor being used. This guide distinguishes single-pass xPOIS, persistent rounds and shared component executors, now available on main.
Why this is needed
The guide explains consumer-local command queues, shared-filesystem launch descriptors, retained worker state and terminal status after shutdown. It separates batch collection from coordinator audits, scientific finalization and external launcher time. Component documentation links identify the available commands and report fields.
The retained 64-worker, eight-GPU and 256-GPU experiments include workload sizes, launch counts, first rounds, startup failures and unrun cases. The guide preserves the unresolved historical first-round spike and distinguishes harness measurements from qualification of current product revisions. The pipeline-versus-stage benchmark is linked separately, with its raw timings and additional hash-verification cost.
Validation: repository pre-commit checks passed; updated relative targets and headings were checked; the guide's Python and Bash examples passed syntax checks. This is a documentation-only change. Historical distributed GPU measurements do not qualify the final executor revisions.