Hello everyone,
I have a static topic with a length of 285 bytes. I want to send this topic data as quickly as possible, preferably to fully utilize the network bandwidth. I don't know how to configure the topic strategy to achieve the effect of the perftest program. I tried using the built-in profile "BuiltinQosLibExp::Generic.StrictReliable.HighThroughput", The effect is not as good as the perftest program，why?
thanks for any help
With small data (<16K Bytes), the only way to fully utilize the network bandwidth is through the use of the Batch QoS Policy.
BATCHQoS policy. For example:<datawriter_qos><batch><enable>true</enable><max_data_bytes>16384</max_data_bytes></batch></datawriter_qos>Increase Send Queue Size: Increase the send queue size to allow more samples to be queued for transmission. This can be done using the
RESOURCE_LIMITSQoS policy:<datawriter_qos><resource_limits><max_samples>1000</max_samples><max_samples_per_instance>1000</max_samples_per_instance></resource_limits></datawriter_qos>Use Built-in QoS Profiles: RTI Connext provides built-in QoS profiles that can be used as a starting point. For example, you can use the
BuiltinQosLib::Pattern.HighThroughputprofile:base_name="BuiltinQosLib::Pattern.HighThroughput"Sources:
Thank you for your reply, but the program runs wrong, like this"RTIXMLObject_initialize:Base object 'BuiltinQosLib::Pattern.HighThroughput' not found", Is there a spelling mistake?
Sorry, you are correct, "
BuiltinQosLib::Pattern.HighThroughput" does not exist. Sorry, I thought that we had such a QoS predefined. Instead, I would suggest that you focus on using the Batch QoS profile.One other thing you should check is to make sure that your application is only using the network interface that you want it to use. By default, Connext will use all of the network interfaces that a host has enabled, UP and RUNNING. Which means if a host has 2 network interfaces, applications will send data 2 times to that host, once to each interface address. If a host has 5 interfaces, applications will send data 5 times. This does not depend on if the sending application can actually reach the host of the receiving application on an address. To restrict the networks that an application uses, you can follow the following advice from our website:
Make sure you are running your tests using the network interface you think you are using.
DDS enables shared memory and UDPv4 transports by default. If Shared memory is available between two nodes DDS will use that by default. But if there are many network interfaces available DDS will only use the first four. I’ve seen developers want to test out a certain network interface, say Infiniband, but it was not one of the first four listed and so DDS was not adding it to the mix. In fact, on Windows systems, the order that network interfaces are listed by the OS, and thus selected by DDS, is random and so the network interface you are actually using can change from run to run. In fact, DDS will actually send the same data over two paths, if they exist, to the same endpoint. This can take up CPU time and slow throughput. You can explicitly select the interface you want (or do not want) using the transport QOS “allow-interfaces” property.
Following is the actual XML code for “allow_interfaces” and “deny_interfaces” QOS that lets you explicitly pick the network interface you want to use or do not want to use:
<participant_qos><property><value><element><name>dds.transport.UDPv4.builtin.parent.deny_interfaces</name><value>10.15.*</value><element><element><name>dds.transport.UDPv4.builtin.parent.allow_interfaces</name><value>10.10.*,192.168.*</value></element></value></property></participant_qos>This should be done for applications running on both the sending and receiving hosts.