Skip to content
This repository has been archived by the owner on Aug 23, 2018. It is now read-only.

Realtime testing RTI Connext example #28

Merged
merged 37 commits into from
Jul 15, 2015
Merged

Conversation

jacquelinekay
Copy link
Contributor

Needs ros2/realtime_support#1

This PR introduces three programs instrumented for real-time performance testing: a standalone publisher, a standalone subscriber, and an intra-process comms example. Each one uses the RTI Connext C++ API.

{
Arguments *new_args = static_cast<Arguments*>(args);
int ret = subscriber_main(new_args);
return static_cast<void*>(&ret);
Copy link
Member

Choose a reason for hiding this comment

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

Looks like you're returning a pointer to a temporary object (ret). What's trying to be accomplished here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nothing, this return code is never used.

Copy link
Member

Choose a reason for hiding this comment

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

Does the signature have to be this way to work with your instrumentation I guess? Either way it should be fine for a test like this if you know it's never being used.

@wjwwood
Copy link
Member

wjwwood commented Jul 9, 2015

This looks good to me. Can you expand on any QoS settings you elected to change, either programmatically or using the xml file, which affect the real-time behavior of these examples? I ask because presumably we'd need to do the same in ROS 2 to accomplish the same results.

@jacquelinekay
Copy link
Contributor Author

This looks good to me. Can you expand on any QoS settings you elected to change, either programmatically or using the xml file, which affect the real-time behavior of these examples? I ask because presumably we'd need to do the same in ROS 2 to accomplish the same results.

sure. The only QoS setting I intentionally changed from what was in the existing examples to get better performance results was changing the "reliable" reliability to "best effort" in the Opensplice examples. But I'm not sure this setting is impacting the performance significantly, since I neglected to specify it in this PR (Connext).

Actually, I could probably spend more time looking into other QoS settings to get better performance out of the examples (History, ResourceLimits, Durability, Availability). @esteve started looking into QoS profiles in ros2/design#36, but perhaps experimenting with which QoS settings are relevant for real-time performance will inform which QoS settings should be exposed to the user in the API. As a side note, I recall we had a significant discussion about how to expose QoS settings in the ROS 2 API and I don't recall what the conclusion was, perhaps we should start that conversation again online to open it up to the community.

@codebot
Copy link
Member

codebot commented Jul 9, 2015

I think you've definitely done the right thing by setting "best-effort"
QoS. That allows the data-writer to just "fire and forget" the samples,
just like if you had a raw UDP socket and were blasting on it. With
"reliable" QoS, it has to remember which samples have been received by all
of the data-readers, and buffer them in case one is garbled in transmission
to a data-reader and it has to re-send it.

On Thu, Jul 9, 2015 at 4:23 PM, Jackie Kay [email protected] wrote:

This looks good to me. Can you expand on any QoS settings you elected to
change, either programmatically or using the xml file, which affect the
real-time behavior of these examples? I ask because presumably we'd need to
do the same in ROS 2 to accomplish the same results.

sure. The only QoS setting I intentionally changed from what was in the
existing examples to get better performance results was changing the
"reliable" reliability to "best effort" in the Opensplice examples. But I'm
not sure this setting is impacting the performance significantly, since I
neglected to specify it in this PR (Connext).

Actually, I could probably spend more time looking into other QoS settings
to get better performance out of the examples (History, ResourceLimits,
Durability, Availability). @esteve https://github.com/esteve started
looking into QoS profiles in ros2/design#36
ros2/design#36, but perhaps experimenting with
which QoS settings are relevant for real-time performance will inform which
QoS settings should be exposed to the user in the API. As a side note, I
recall we had a significant discussion about how to expose QoS settings in
the ROS 2 API and I don't recall what the conclusion was, perhaps we should
start that conversation again online to open it up to the community.


Reply to this email directly or view it on GitHub
#28 (comment).


mkdir build
cd build
cmake ..
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this be configured with -DCMAKE_BUILD_TYPE=Release?

@tfoote
Copy link

tfoote commented Jul 10, 2015

lgtm

@dirk-thomas
Copy link
Contributor

LGTM but I haven't built / ran the programs.

jacquelinekay added a commit that referenced this pull request Jul 15, 2015
Realtime testing RTI Connext example
@jacquelinekay jacquelinekay merged commit 96d0648 into master Jul 15, 2015
@jacquelinekay jacquelinekay deleted the realtime_connext branch August 10, 2015 22:11
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants