dds udp communication need two much cpu resource when it send big message？

[fengmao31]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

I defind a message include string and other common structure.
I test to use 1KB 10KB 100KB 1MB 6MB size string and test them delay.

Current behavior

I find when it is 1MB size, it use 32% CPU. when it is 6MB, it use 100% CPU. I think it is becuease of the CDR serialization

Also, all of them have almost same time to send to another pc.

Steps to reproduce

defind a mesage include string and other common structure datatype such as int.
and use string a(10000,'+') to set the value. append the time in the end of the string and send it to another pc. you can get the last time in the message and compute the variance with the now time.

Fast DDS version/commit

It is 15 version.

Platform/Architecture

Ubuntu Focal 20.04 arm64

Transport layer

UDPv4

Additional context

I hope the dds can transport the big message. it looks like that the serialization use too much cpu resource and stop dds from sending big message. it make people try to use zmq. but we all know udp is more fast and tcp is not good for soft realtime system.

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[JLBuenoLopez]

Thanks for the report @fengmao31,

Which Fast DDS version are you using? The provided information provided in the ticket is not helpful because it does not correspond to any Fast DDS release or commit hash. Also, which hardware are you using? This could be a constraint on the hardware resources as you are running on arm64 architecture. The CDR serialization/deserialization is defined in the corresponding OMG specification. There could be an issue in the implementation, so a reproducer might be helpful in that case.

[fengmao31]

what setting will block the using of hardware resources in the linux.

[fengmao31]

In fact, I want to find a way to transport the big message. and I transform them to string and insert this in the CDR serialization/deserialization to transport in the DDS. but it use the too much CPU in the system.

[JLBuenoLopez]

If you are referring to FastRTPS v1.5.0 I am afraid that it is no longer supported. I strongly suggest you update to a supported version. You can see which versions are supported in the Fast DDS release lifecycle.

Concerning the hardware, if memory resources in the host are not enough, it is expected for the CPU to be unable to process large messages. That is the reason why the DDS-XRCE specification exists. Maybe you should consider using eProsima Micro XRCE-DDS.

I have moved the issue to the support discussion forum until it is proven that a bug exists in the most modern Fast DDS version or one of the supported releases.