Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[iron] add test to check for execution order of entities in various executors #2561

Closed

Conversation

wjwwood
Copy link
Member

@wjwwood wjwwood commented Jun 12, 2024

This is the Iron version of #2536 and passes without changes to the actual source of rclcpp, which supports the idea that this test is actually testing a regression between iron and jazzy. The fix for jazzy/rolling has been proposed here: #2537

Signed-off-by: William Woodall <william@osrfoundation.org>
Signed-off-by: William Woodall <william@osrfoundation.org>
Signed-off-by: William Woodall <william@osrfoundation.org>
Signed-off-by: William Woodall <william@osrfoundation.org>
Signed-off-by: William Woodall <william@osrfoundation.org>
Copy link
Member

@mjcarroll mjcarroll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with green CI

@wjwwood
Copy link
Member Author

wjwwood commented Jun 19, 2024

CI:

  • Linux Build Status
  • Linux-aarch64 Build Status
  • Linux-rhel Build Status
  • Windows Build Status

@wjwwood
Copy link
Member Author

wjwwood commented Jun 20, 2024

I messed up the CI, here's some hopefully fixed runs:

  • Linux Build Status
  • Linux-aarch64 Build Status
  • Linux-rhel Build Status
  • Windows Build Status

Signed-off-by: William Woodall <william@osrfoundation.org>
@wjwwood
Copy link
Member Author

wjwwood commented Jun 25, 2024

CI after uncrustify fix:

  • Linux Build Status
  • Linux-aarch64 Build Status
  • Linux-rhel Build Status
  • Windows Build Status

@wjwwood
Copy link
Member Author

wjwwood commented Jun 25, 2024

Unfortunately the order of execution for timers seems to be subtly out of the expected order on Windows 🤦 . I'll look into it more tonight.

for (size_t i = 0; i < number_of_entities; ++i) {
// "call order" for timers will be simulated by setting them at different
// periods, with the "first" ones having the smallest period.
auto period = 1ms + std::chrono::milliseconds(test_case.call_order[i]);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

according to https://ci.ros2.org/job/ci_windows/22053/testReport/projectroot.test/rclcpp/test_executors/

values:
  actual_order
    Which is: { 18, 19, 17, 16, 14, 15, 13, 12, 10, 11, 9, 7, 8, 6, 5, 4, 2, 3, 1, 0 }
  test_case.expected_execution_order
    Which is: { 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 }

means timers with period 1ms (in the end of the list of callbackgroup) and 2ms (2nd from the end) are ready when the 1st execution, then executor takes out the timer with 2ms since that is in front of timer with 1ms? it seems that this situation only happens 1st spin execution, that means probably when the executor spins and call `rcl_wait, it has been already 1ms passed?

if above assumption is right, maybe 1ms is too short for windows... (if that is either rolling or jazzy, we can create the timer with auto_start = false, and the reset the timer right before the spin. that would save some time for the 1st execution.)

@clalancette
Copy link
Contributor

Since this is targeting Iron, which is going EOL soon, I'm going to close this out.

@wjwwood if you think it makes sense to retarget this to rolling, please feel free to reopen and retarget.

@clalancette clalancette closed this Nov 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants