You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR adds three command line arguments to the benchmark application
parameter-server: Enable/disable parameter server. The parameter server is by default activated, and therefore some services are created when creating a ROS 2 node. This has an impact in the memory consumption that is not representative of the use case, since the benchmark does not use these services.
wait-pdp: Enable/disable waiting for pdp discovery. Whether or not to wait for participant discovery before starting sampling. This flag is for instance necessary when testing for Fast-RTPS with participant whilisting, because in that case, each participant only matches with the ones in its whitelist, resulting in less "matches" than what performance_test::System::wait_pdp_discovery() is expecting.
wait-epd: Enable/disable waiting for edp discovery.
* Enable/disable parameter server (since the application does not use it)
* Enable/disable waiting for pdp discovery
* Enable/disable waiting for edp discovery
Signed-off-by: EduPonz <eduardoponz@eprosima.com>
What about merging wait-pdp and wait-edp into a single option wait-discovery?
I don't see cases where it may be useful to enable only one but not the other (moreover, if wait-pdp is for any reason set to false, wait-edp does not make a lot of sense)
Yeah, actually spin() was taking a wait-discovery boolean that was always passed as true. The only reason to separate them is because in our try-outs with the participant white-list (we are filtering participants in the participant discovery protocol), we were actually commenting out wait_pdp_discovery() (as I describe in #8) and were only using wait_edp_discovery(). In this sense, if the feature request #8 is tackled, then it wouldn't make sense to separate wait-pdp and wait-edp. That would in my opinion be the best option.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds three command line arguments to the benchmark application
parameter-server: Enable/disable parameter server. The parameter server is by default activated, and therefore some services are created when creating a ROS 2 node. This has an impact in the memory consumption that is not representative of the use case, since the benchmark does not use these services.wait-pdp: Enable/disable waiting for pdp discovery. Whether or not to wait for participant discovery before starting sampling. This flag is for instance necessary when testing for Fast-RTPS with participant whilisting, because in that case, each participant only matches with the ones in its whitelist, resulting in less "matches" than whatperformance_test::System::wait_pdp_discovery()is expecting.wait-epd: Enable/disable waiting for edp discovery.