The message-rate throughput numbers we post at http://www.rti.com/products/dds/benchmarks-cpp-linux.html, to which I was referring, are measured in units of DDS samples per second. (A “sample” is the object you pass to the DDS write() call.) You’re correct that a packet send rate in the tens-of-thousands is typical. However, a DDS sample may or may not correspond one-to-one to a UDP packet. For example:

–> If you’ve configured RTI Data Distribution Service to batch data, many samples will be combined into a single UDP packet to reduce the number of trips through the IP stack. This is the configuration we use to generate our published results.

–> If your sample size is greater than the maximum UDP datagram size (64 KB, or smaller on some embedded OSes), RTI Data Distribution Service will fragment a single logical sample over multiple UDP packets and then reassemble them on the receiving side.

Given that, there are a number of factors that can explain the differences between our published performance numbers and what you’re seeing.

1. The platform and networks are different. As explained on our performance results page (URL above), as of this writing, we generate our published numbers using 2.4 GHz dual-core machines connected to a gigabit ethernet network. That hardware is significantly more capable than what you’ve indicated you’re using. In particular, your 100-Mbit network has 10x less capacity than our testing environment, so you can expect a theoretical maximum throughput close to 100K samples/sec than to 1M samples/sec.

2. The batching configuration may be different. By default, RTI Data Distribution Service does not batch samples, because doing so can impact latency. Based on the results you’re seeing, you may not have altered this default setting. Look in your code or XML QoS profile file for the BatchQosPolicy, which is configured on the DataWriter entity. If you’re not familiar with this policy, you can find more information in the API documentation that’s included in your product distribution.

3. The sample sizes may be different. Note on the graph how the sample rate falls off as the sample size increases. At very small sizes, this reflects the increasing cost of copying larger amounts of data. Once the network becomes saturated, it reflects the purely mathematical relationship (number of samples) ~= (network capacity) / (sample size).

There are a couple of things you can do to reduce #2 and #3 above.

–> If you’d like to run our test configurations on your hardware directly, you can download our example performance test. Visit our Knowledge Base at https://www.rti.com/kb/index.html, click “Performance,” then click “Example Performance Test for RTI Data Distribution Service.” This is the exact code we use to generate our published numbers.

–> Even easier: if you’re using a recent version of RTI Data Distribution Service, you can find an example QoS profile configuration in your product distribution. Look in example/QoS/high_throughput.xml.

I hope this was helpful.
Best regards,
- Rick

If I am interpreting your statement of 1 million samples persecond as 1 million UDP packets that would mean it takes 1 microsecond to run up or down the TCP/IP stack. This is much faster then anything I have measured. Is my interpretation of your data correct?