Repository navigation
fix(diag): print the NIC queue state next to every timeout - #29
Conversation
58dfc03 to
2c36506
Compare
2c36506 to
fdd2b68
Compare
|
Tested on 2× p6-b300 (NCCL 2.31.2). Full matrix + pressure pass; perf flat with and without |
fdd2b68 to
a39dead
Compare
d1aefbc to
f55c518
Compare
hershys-aws
left a comment
There was a problem hiding this comment.
Main suggestion is on handle.cuh:216: a timed flush in the report gives the same answer without changing put or the QP it posts on. The rest are smaller: the thread-0 guards can drop the report, the elected lane needs a __syncwarp before the trap, and a few report sites (local waits, barrier) can't say much. Tested on 2x8 H200 with planted faults; happy to share the scripts.
f55c518 to
49e3929
Compare
49e3929 to
5b5e7e2
Compare
A timeout says that a peer's data or signal did not arrive, not whether this rank's own NIC delivered what it was given. With EP_DEBUG_CHECKS=queue the unordered dispatch and combine, the Gin barrier and the GIN flush timeouts give the waiting warp's GIN context a short timed flush and print whether the NIC had completed every write posted on it, so a NIC that holds our writes can be told from a peer that never sent. The lowest active lane does the flush and the print and the other lanes wait for it, so the report is not lost when another lane traps first; a GIN flush timeout then also names its context and waits a second before trapping. EP_DEBUG_CHECKS is a comma-separated list of check names (`1` or `all` turns on every check, an unknown name stops at buffer creation); the host maps the names to bits before the JIT compile, so the default build carries none of this code. The check is off by default because an inlined gin.flush at every wait site changes the register allocation of the hot kernels even though it never runs.
5b5e7e2 to
beea155
Compare
A timeout says that a peer's data or signal did not arrive, not whether this GPU's own NIC delivered what it was given.
comm::report_gin_queuereads the posted and completed counts of the waiting warp's GIN context from the EFA GDA device handle and prints them after every timeout line of the unordered dispatch and combine, the Gin barrier and the GIN flush. After the kernel timeout every WQE should have completed long ago, so a non-zero count means this NIC or the fabric still holds our writes.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.