What does Fast-DDS maxInitialPeersRange restrict?
This is a follow up question on https://answers.ros.org/question/3249....
What does the maxInitialPeersRange
that can be configured on the TransportDescriptor really do? As mentioned in the linked question / answer, does it limit the number of nodes a node can communicate with?
I tried using the following as the contents of my DEFAULT_FASTRTPS_PROFILES.xml
:
<?xml version="1.0" ?>
<profiles>
<transport_descriptors>
<transport_descriptor>
<transport_id>lotsOfPeers</transport_id>
<type>UDPv4</type>
<maxInitialPeersRange>100</maxInitialPeersRange>
</transport_descriptor>
</transport_descriptors>
<participant profile_name="participant_profile" is_default_profile="true">
<rtps>
<builtin>
<metatrafficUnicastLocatorList>
<locator/>
</metatrafficUnicastLocatorList>
<initialPeersList>
<locator>
<udpv4>
<address>127.0.0.1</address>
</udpv4>
</locator>
</initialPeersList>
</builtin>
<userTransports>
<transport_id>lotsOfPeers</transport_id>
</userTransports>
</rtps>
</participant>
</profiles>
Now I noticed that using this setup, if I run the service server and client demo, the latencies are quite high.
Terminal 1:
$ ros2 run demo_nodes_cpp add_two_ints_server
Terminal 2:
$ while true; do time ros2 run demo_nodes_cpp add_two_ints_client; sleep 1; done;
[INFO] [1600895510.402647349] [add_two_ints_client]: service not available, waiting again...
[INFO] [1600895511.403126903] [add_two_ints_client]: service not available, waiting again...
[INFO] [1600895511.839904424] [add_two_ints_client]: Result of add_two_ints: 5
real 0m2.669s
user 0m0.215s
sys 0m0.049s
[INFO] [1600895514.082000200] [add_two_ints_client]: service not available, waiting again...
[INFO] [1600895514.919007937] [add_two_ints_client]: Result of add_two_ints: 5
real 0m2.075s
user 0m0.212s
sys 0m0.060s
[INFO] [1600895517.155697003] [add_two_ints_client]: service not available, waiting again...
[INFO] [1600895517.918913346] [add_two_ints_client]: Result of add_two_ints: 5
real 0m2.001s
user 0m0.231s
sys 0m0.039s
When I remove the DEFAULT_FASTRTPS_PROFILES.xml
file, the latency goes down consistently to something between 0.2 and 0.4 seconds.
I found out that the main trigger for this is the maxInitialPeersRange
, anything below 36 seems to be good in my current setup.
Based on the answer I mentioned earlier, a low maxInitialPeersRange
would result in nodes not being able to communicate with each other, however I can set maxInitialPeersRange
to 1
and run ros2 run demo_nodes_cpp talker
with 20 instances of ros2 run demo_nodes_cpp listener
and eventually all 20 listeners will be receiving the data.
I haven't been able to figure out how maxInitialPeersRange
influences the communication except for the latency at values beyond 36.