ROS2 topic bandwidth seem doubled on netstat apps
Hi I'm using ROS2 foxy on a client and a server, the client transmits raw image data to server via ethernet the data transmits successfully but as I uses ros2 topic bw /camera/infra1/imagerectraw to see the bandwidth overhead and uses bmon to see the overall network traffic. It has difference that the traffic at bmon are approximately doubled than ros2 bw.
And this is just a testing so I only open the camera nodes at client side and uses ros2 topic bw at server side
ubuntu@ubuntu-Default-string:~$ ros2 topic bw /camera/realsensesplitternode/output/infra_1
Subscribed to [/camera/realsensesplitternode/output/infra_1]
12.33 MB/s from 30 messages Message size mean: 0.41 MB min: 0.41 MB max: 0.41 MB
12.27 MB/s from 60 messages Message size mean: 0.41 MB min: 0.41 MB max: 0.41 MB
12.25 MB/s from 90 messages Message size mean: 0.41 MB min: 0.41 MB max: 0.41 MB
12.25 MB/s from 100 messages Message size mean: 0.41 MB min: 0.41 MB max: 0.41 MB
12.26 MB/s from 100 messages Message size mean: 0.41 MB min: 0.41 MB max: 0.41 MB
12.27 MB/s from 100 messages Message size mean: 0.41 MB min: 0.41 MB max: 0.41 MB
12.27 MB/s from 100 messages Message size mean: 0.41 MB min: 0.41 MB max: 0.41 MB
12.28 MB/s from 100 messages Message size mean: 0.41 MB min: 0.41 MB max: 0.41 MB
for the bmon since I cannot upload screenshots, the outputs are bmon: RX bps eno1 23.91MiB
so when I turn off the ros2 bw, the ros2 bw and bmon traffic are all dropped, bmon traffic are about 2KBps
is there anything wrong or am I missing something in ROS2? Any assistance would be appreciated, thanks.
Asked by chivas1000 on 2022-10-28 02:50:42 UTC
Answers
This is expected behavior. ros2 topic bw
subscribes to the topic, so all the data is sent to two destinations.Therefore the bandwidth may double on a particular interface while bandwidth measurement is running.
Asked by Mike Scheutzow on 2022-10-29 14:33:26 UTC
Comments
Thanks for the reply
But still I am not quite understand why all the data is sent to two destinations since I thought there would be only one subscriber at server if I only use ros2 topic bw and no other subscriber, could you explain more details about what is these two destinations?
and for the actuall traffic, is that the data only transmit one time on the network(I mean between the client and server)
Thank you for your help!
Asked by chivas1000 on 2022-10-29 23:20:50 UTC
If you are sure that ros2 topic bw
is the only subscriber, then something else is using that extra bandwidth. Which DDS Quality of Service (QoS) is the topic using?
http://design.ros2.org/articles/qos.html
Asked by Mike Scheutzow on 2022-11-01 08:46:25 UTC
Have you figured out the cause of this apparent bandwidth doubling?
Asked by Mike Scheutzow on 2022-11-20 10:25:13 UTC
@Mike Scheutzow, Hi and thanks for the concern, I switched to node discovery server which runs like ROS1 https://fast-dds.docs.eprosima.com/en/v2.3.1/fastdds/ros2/discovery_server/ros2_discovery_server.html and the problem disappears, but I hasn't further explore the original problems, thank you
Asked by chivas1000 on 2022-11-21 00:50:16 UTC
I don't have any idea about the discovery server.
I see the exact same double bandwidth consumption issue in ROS1 noetic too.
I tried switching the client and server, but the result is the same, every time sender and receiver consumes double bandwidth than 'rostopic bw -w 30 \topic_image\compressed'. Bandwidth is monitored with 'system monitor' app.
Is there anyone observing the same issue? Any solution?
Master:
export ROS_IP=10.72.111.48
export ROS_MASTER_URI=http://10.72.111.48:11311
Slave
export ROS_IP=10.72.111.58
export ROS_MASTER_URI=http://10.72.111.48:11311
Asked by JeyP4 on 2023-07-28 12:02:44 UTC
@JeyP4 The topic publish and subscribe code is completely different between ros1 and ros2, so please open your own question for your ros1 issue.
Asked by Mike Scheutzow on 2023-07-29 05:55:14 UTC
Thanks @Mike Scheutzow. I opened a new topic Double network bandwidth consumption than rostopic bw!
Asked by JeyP4 on 2023-07-29 06:46:21 UTC
Comments