Unexpected latency behaviour about rmw

[tfoote]

At first glance you're using spin_some in the publish loop and then sleeping until the next publish. I would expect that you then are only giving rclcpp the opportunity to check for incoming messages each time you publish, which thus causes your latency to be correlated to your publish frequency.

I'd suggest refactoring to make sure to have spin active all the time by putting it in a dedicated thread. Or even simpler would be to setup a timer to trigger your publish events and then you can just call spin in the main thread.

[Alex031544]

Hello,

thanks for your replay. This makes sense and was very helpful. Now the latencies are constant over the frequency. This is totally what we expected. But there is a new observation: During the transmission data losses occur over a longer time. This leak time increases with the frequency and occurs only with WLAN connections. Have you an idea why this happens?

Obeservations

D-Link DIR-645 (LAN)

• 25 Hz
  
• 50 Hz
  
• 100 Hz
  
• 200 Hz
  
• 400 Hz
  

TP-Link M7350 (5 GHz WLAN)

• 25 Hz
  
• 50 Hz
  
• 100 Hz
  
• 200 Hz
  
• 400 Hz
  

TP-Link M7350 (2G4 Hz WLAN)

• 25 Hz
  
• 50 Hz
  
• 100 Hz
  
• 200 Hz
  
• 400 Hz
  

Setup

Now I seperate the sender and receiver tasks in two classes. The sender has an own thread for his work, while the receiver only bind the callback function to the topic. The spin comes directly before the class-destructors inside the main function:

    // initialize ROS2
    rclcpp::init(argc, argv);
    // initialize a node
    auto node = rclcpp::node::Node::make_shared(flzNodeName);

    // take a reference time stamp
    auto t_start = std::chrono::steady_clock::now();

    auto *iomReceiver = new test::IomReceiver( node, flzNo, t_start );
    auto *iomSender = new test::IomSender( node, flzNo, t_start, freq );

    rclcpp::spin(node);

    delete iomReceiver;
    delete iomSender;

The QoS-profile is again rmw_qos_profile_sensor_data.

[dirk-thomas]

When using best-effort I would expect messages to be lost when being sent over a wireless connection. If packet collision happens the message will not be resend and therefore never be received. If you switch to reliable that should not happen.

[Alex031544]

Yes this is clear. But what I don't see why this happens in that way. The network has totally only this two "members" and only this data exchange. Over a longer period with some hundred messaged all goes perfectly. And then comes a short period of collisions? Why, all of a sudden, collisions? Maybe there is something black magic from the router?

To solve this by setting the profile to be reliable truly is a way. But on our 400 Hz measurement this will lead to hold maybe up to 80 messages. Is it right to say this will additionally increase the data traffic? If it is so I think maybe it is a good thing to think about the reasons for this. Because the bandwidth is limited and we go to have up to 10 IOMs in a further development step.

[dirk-thomas]

You might want to run wireshark on that interface and look at the exchanged packets. A lot of stuff is going on in a (wireless) network even if it is "idle" from the user point of view.

[Alex031544]

Yeah - I think we should examine this. Sad, that the small modern mobile routers don't support a good QoS-set-up to avoid disturbing parallel communications. (DIR-645 <> DIR510L / TP-Link M7350)

On a DIR-645 it's possible to set up priorities and it seems to lead to better results.

[mikaelarguedas]

@Alex031544 I'm going to close this due to the low activity for a while. If you want to share the results of your investigation, please feel free to comment here and we can reopen this if needed