ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
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).
2 | No.2 Revision |
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.