UCP/GTEST: Add test for multi-rail load-balance - #11842
Conversation
|
🤖 Starting review — findings will be posted here when done. |
| size_t expected_bytes, | ||
| const std::map<std::string, double> &expected_rates) | ||
| { | ||
| constexpr double byte_tolerance = 1.0; |
There was a problem hiding this comment.
minor: pls align the = on a common column here; the CodeStyle rule is that the longest LHS (const ucp_lane_index_t num_lanes) gets one space before = and the rest align to it, but byte_tolerance and the others don't line up.
Signed-off-by: Zhenlong Ma <zhenlongm@nvidia.com>
c836193 to
a57c61b
Compare
|
🤖 Starting review — findings will be posted here when done. |
| size_t expected_bytes, | ||
| const std::map<std::string, double> &expected_rates) | ||
| { | ||
| constexpr double byte_tolerance = 1.0; |
There was a problem hiding this comment.
the per-lane split is computed with round-up fixed-point weights (ucp_proto_multi_scaled_length() uses div_round_up), so the actual bytes on each device are not the exact expected_bytes * rate / total_rate value used here. is a 1-byte tolerance robust across the possible weight rounding, or could it be flaky? if it depends on the specific 52K/38K message sizes, maybe add a short comment noting why these sizes were chosen.
2 participants
What?
Add a stats-enabled unit test for multi-rail load-balance after a device speed-change event. The test verifies that PUT and GET operations can distribute and reallocate transmission data across two rails based on their actual rates.
Why?
The existing unit test for speed-change only verify the configuration without checking the actual data on each rail. As a result, we need additional tests to guarantee that UCX adopt the latest and correct multi-rail speed distribution.
How?
The test records the byte counters for every lane before and after the data transmission and compares them with the expected distribution.