ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

We also noted this previously and it looks like this indeed generally starts showing up when exceeding a specific message size (apparently 519 bytes). When using the ros::TransportHints().tcpNoDelay(true) subscriber option, the problem disappeared for me in one crucial use case (example here), suggesting that the observed symptoms are related to Nagle's algorithm at work. I don't completely understand how, however, as smaller sizes should be affected as well. I also seem to remember others reporting not seeing an improvement using the tcpNoDelay option, so I'd also be interested in a explanation.

The two options to try and reduce delays I see are using tcpNoDelay as mentioned or using udpros (which limits allowed message size and might has other caveats depending on use case).

We also noted this previously and it looks like this indeed generally starts showing up when exceeding a specific message size (apparently 519 bytes). When using the ros::TransportHints().tcpNoDelay(true) subscriber option, the problem disappeared for me in one crucial use case (example here), suggesting that the observed symptoms are related to Nagle's algorithm at work. I don't completely understand how, however, as smaller sizes should be affected as well. I also seem to remember others reporting not seeing an improvement using the tcpNoDelay option, so I'd also be interested in a explanation.

The two options to try and reduce delays I see are using tcpNoDelay as mentioned or using udpros (which limits allowed message size and might has other caveats depending on use case).

/edit: It might be the case that all instances of this issue I've seen were ones where data was actually sent over the wire (Ethernet) as opposed to local loopback.