Comments (2)
Hi @nabetetsu, I guess you also went from -5
is DDS_RETCODE_OUT_OF_RESOURCES
and in this case that means sendmsg
returned either ENOBUFS
or ENOMEM
, and that it therefore looked like the send buffer was too small. Somehow.
The thing is that I can't remember actually having seen this error myself on Linux (I think I have seen it on macOS once or twice). The default socket send buffer is small, and by default the sendmsg
call blocks until the network has accepted the data. The mere fact you're trying to send some data doesn't usually cause that. Maybe it happens when there are many processes writing at the same time, from what I remember that seemed to play a role on macOS. For me, that time, it was all on one machine and I suspected the many-to-one packets over the loopback interface to be the trigger, but it is really just a guess.
If ss -pm
doesn't tell anything, then I guess one has to fly blind.
For the send buffer, I always think it is better if it is kept small, otherwise all you're getting is extra latency. Cyclone can handle the packet drops, so it should work fine despite these errors. That means it might actually be best to not print anything when it happens. It already suppresses some error codes that I learnt I have to expect at
cyclonedds/src/core/ddsi/src/ddsi_udp.c
Line 280 in 15b3a09
For the receive buffer, it depends. If you want to receive large samples without packet drops, then I would recommend making it large enough to hold the largest sample (plus some "reasonable" overhead). If you have multiple sources sending them at the same time, you might have to make it a bit larger still.
If you can afford losing some packets and recovering via retransmits, then Cyclone generally does a decent job even when the receive buffer is much smaller, because it will take the actual receive buffer size into account in deciding how much to retransmit in one go and so it generally avoids overflowing the buffer with the retransmits. Still, you lose bandwidth (to packets lost in the initial transmission) and you incur the latency of some round-trips and some scheduling/processing overhead.
Most of the time, a large receive buffer is fine. If the receive processing can keep up nearly all the time, you won't introduce excessive latency in the buffer, and Linux (and macOS and Windows) only allocates memory that you actually use. If you have 100 processes and 10MB socket receive buffers, you have worst-case of 4GB or so (4 sockets per process), which is still manageable on many machines, but in practice 3 of those sockets will not be handling that much traffic and so won't be using all that memory anyway.
Are there any best practices for setting up an appropriate send buffer size ? (and also receive buffer size)
Not really ... but perhaps the above helps you a bit in deciding.
from cyclonedds.
Hi @eboasson, It was very helpful to hear your insights.
As you guessed, I assumed from DDS_RETCODE_OUT_OF_RESOURCES error code that sendmsg() actually resulted in ENOBUFS or ENOMEM error.
I guessed that sendmsg() was running non-blocking and the corresponding error occurred because the send buffer was overflowing, but I guess I was wrong in my assumption.
For the send buffer, I always think it is better if it is kept small, otherwise all you're getting is extra latency. Cyclone can handle the packet drops, so it should work fine despite these errors. That means it might actually be best to not print anything when it happens. It already suppresses some error codes that I learnt I have to expect at
I agree with your opinion. If it is going to output an error, it might as well be when the retransmission process at Cyclone layer finally fails and discards the packets.
Due of Cyclone's retransmission process, it seems that I do not have to watch the output of retcode -5 errors, but since they occur several times per second in my case, I will consider the send buffer size needed to suppress error outputs.
So far, in my case, the problem has not occurred because I have set the receive buffer large enough. However, as you said, if the problem occurs on the receiving side, I recognized that the problem shold be that the receiving process is not keeping up with the receiving buffer size, rather than reviewing buffer size.
from cyclonedds.
Related Issues (20)
- Is there a way to replicate the deserialization mechanism used in Cyclone DDS, such as the pycdr2 library, but in the C programming language? HOT 2
- Issues with using Zenoh_bridge_dds to route data between domains HOT 9
- An implementation for dds_stream_writeLE could not be found HOT 3
- typedef in idl why not generate xxx__free() HOT 1
- CycloneDDS and eProsima Micro XRCE-DDS Communication in ROS2 HOT 6
- Allow inconsistent about DurabilityService QoS HOT 1
- Is there an implementation of Shared memory that does not through Iceoryx HOT 1
- Does CycloneDDS automatically group subscribers into multicast groups based on topic?
- Deserialization of sample failed due to reasons unknown, possibly related to a sequence HOT 29
- Two processes with the same language can communicate, but two processes with two different languages ββcannot communicate HOT 4
- How to subscribe to multiple topics?
- The dds_get_matched_subscription_data function be called in publication_matched listener, It can't get proxy reader's information HOT 3
- Malformed packets when streaming large messages over Ethernet HOT 5
- The frequency of subscription topic triggering is inconsistent with the frequency of publishing
- Provide Documentation to toggle between xcdr1 and xcdr2 ? HOT 2
- Checking handshake of a "topic" in a network? HOT 2
- How to config dds if using VLAN? HOT 1
- How to communicate with ROS2 and cyclonedds? HOT 1
- Does Data(M) carry unregister dispose information? what is the scenarios? HOT 1
- Questition: what is the ddsi2 participant for ?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cyclonedds.