•  
  •  

Benchmarking DDS Implementations

The existence of different DDS implementations motivates the execution of performance comparisons across them. In this article, eProsima presents a comparison between Fast DDS and Eclipse Cyclone DDS, comparing both latency and throughput performance.

In all the tested cases, Fast DDS exposes a lower latency and higher throughput than Cyclone DDS. Continue reading for detailed information.

Benchmarking DDS Implementations - INDEX

This article is divided into the following sections:

Latency Comparison

The latency tests have been executed in two different scenarios:  intra-process and inter-process.

Latency Results: Intra-process

Latency Results: Inter-process

Latency Results: Conclusion

The comparison of Fast DDS and Cyclone DDS in terms of latency performance shows that Fast DDS’s mean latencies are lower than that of Cyclone DDS, meaning that Fast DDS is the fastest message delivery implementation in all the tested cases. Furthermore, it is important to note that Fast DDS is also the more stable DDS implementation, indicated by a slower increase of latency as the payload gets larger.

Back to Benchmarking Index

Methodology: Measuring Latency

In network computing, latency is defined as a measurement of the amount of time that a message spends traversing a system, i.e. it is a measurement of how much time passes since the message is sent by the sender (a Fast DDS DastaWriter in our case) until it is received by a receiver (a Fast DDS DataReader). To avoid clock synchronization issues between the systems where DataWriter and DataReader lie, a common way to approximate latency is by the means of the round-trip time. In this scenario, the DataWriter sends a message and waits for the DataReader to send it back (much like a ping-pong paradigm), measuring the elapsed time between DataWriter’s send action to DataWriter’s receive action. Then, to get a latency approximation, the measured round-trip time is divided by two.

Back to Benchmarking Index

Latency Tests details

  1. This comparison has been established by performing experiments with the following tools:
    • Fast DDS’ LatencyTest
    • Cyclone DDS’ RoundtripPing and RoundtripPong
  1. Both DDS applications have been configured with the same DDS quality of service (QoS) parameters.
  2. The experiments have been performed running both the sender and the reader in the same machine (localhost).
  3. The experiments are performed for 11 different message sizes: 64, 512, 1024, 4096, 8192, 16384, 65536, 1048576, 2097152, 4194304 and 8388608 bytes.
  4. To perform the experiments, 10000 messages are sent for each message size, and the minimum and average measurements are extracted.

DDS QoS

A quick overview of the DDS QoS configuration is provided in the following table. For further inquiries about the purpose of each of the parameters please refer to the Fast DDS documentation.

  • Reliability: RELIABLE
  • History kind: KEEP_LAST
  • History depth:1
  • Durability: VOLATILE

Back to Benchmarking Index

Throughput Comparison

The latency tests have been executed in one scenario: inter-process.

As Cyclone DDS does not provide a test for intra-process, eProsima was not able to include this second scenario for the throughput performance benchmark.

Throughput Results: Inter-process

Fast DDS v2.2.0 (zero-copy) data has solely been included in the first graphic in order to provide a better visualization of the remaining versions in the other two graphics.

Throughput Results: Conclusion

The inter-process comparison shows a clear difference between Fast DDS and Cyclone DDS. It can be seen that Fast DDS’s throughput is the highest for every payload, meaning that Fast DDS is able to send more messages of a given size per second for every payload considered.

Back to Benchmarking Index

Methodology: Measuring Throughput

In network computing, throughput is defined as a measurement of the amount of information that can be sent/received through the system per unit time, i.e. it is a measurement of how many bits traverse the system every second. The normal measuring operation is for a DataWriter to send a large group of messages (known as batch, burst or demand) within a certain time (burst interval). After finishing the sending, if the operation has taken less time than the burst interval, the DataWriter is put to rest until the interval has completely elapsed (else, the publisher is not allowed to rest). This operation is performed until the test time is reached. On the receiving side, a DataReader is receiving the information, taking note of the time when the first message was received, and counting every message that arrives. When the test is complete, the DataReader can compute a receiving sample rate. Knowing the size of every message (in bits), the throughput is simply the product of the sample rate times the message size. The following diagram illustrates this process.

Throughput Test Details

  1. This comparison has been established by performing experiments with the following tools:
    • Fast DDS’ ThroughputTest
    • Cyclone DDS’ ThroughputPublisher and ThroughputSubscriber examples
  2. Both applications have been configured with the same DDS quality of service (QoS) parameters, which have required to apply code patches to Cyclone DDS 
  3. The experiments have been performed running both the writer and the reader in the same machine (localhost).
  4. The localhost experiments are performed for 11 different message sizes: 64, 512, 1024, 4096, 8192, 16384, 65536, 1048576, 2097152, 4194304 and 8388608 bytes.
  5. To perform the experiments, demands of 100, 1000, 10000, 30000, 40000, and 50000 number of messages are used.
  6. To perform the experiments, burst intervals of 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, and 100 ms are used.
  7. The results presented in this article correspond to the maximum throughput found among all the combinations from points 5 and 6.

DDS QoS

A quick overview of the DDS QoS configuration is provided in the following table. For further inquiries about the purpose of each of the parameters please refer to the Fast DDS documentation.

  • Reliability: RELIABLE
  • History kind: KEEP_ALL
  • History depth:1
  • Durability: VOLATILE

Back to Benchmarking Index

Testing environment

The experiments have been performed at eProsima’s facilities using one PowerEdge R330 e34s running a Linux 5.4.0-53-generic kernel and Ubuntu 20.04.1 LTS. The machine’s specifications are:

  • Architecture: x86_64
  • CPU(s): 8
  • Thread(s) per core: 2
  • Model name: Intel(R) Xeon(R) CPU E3-1230 v6 @ 3.50GHz

Middleware Versions:

  • Fast DDS v2.2.0: 70e2ad09001cbe92eea7bfe66830099b96b6f7d4 
  • Cyclone DDS 0.7.0: c261053186c455abc63ca5ac7d56c0808a59c364

Back to Benchmarking Index

Further information

For any questions about the methodology used to conduct the experiments, the specifics on how to configure Fast DDS or any other question you may have, please do not hesitate in contacting This email address is being protected from spambots. You need JavaScript enabled to view it. 

Back to Benchmarking Index