•  
  •  

Latency Comparison

The existence of different DDS implementations motivates the execution of performance comparisons across them. In this article, a comparison between Fast-RTPS, CyclondeDDS, and OpenSplice in terms of latency performance is presented, showing that Fast-RTPS is the fastest message delivery implementation in all the tested cases. Furthermore, Fast-RTPS is the most consistent one when dealing with message delivery delays. This all means that, with Fast-RTPS, the experienced latency is the shortest, and it remains almost the same at all times.

This article is divided into the following sections:

  • Results: Localhost Comparison - Inter-process
  • Results: Localhost Comparison - Intra-process
  • Results: DualHost Comparison
  • Methodology
  • Testing environment
  • Tests details
  • Further information

Results: Localhost comparison - Inter-process

 

Results: Localhost comparison - Intra-process

Results: Dual Host comparison

 

Conclusion

Both the localhost and the dual host comparisons show a clear difference between Fast-RTPS and the other two implementations, in favor of the former. It can be seen that Fast-RPTS mean latencies are smaller than the other implementations’ minima at all times. It is important to note that Fast-RTPS latency is stable for more payloads, increasing with a smaller increasing rate in the larger payloads than CycloneDDS or OpenSplice. In this scenario, it is also notable that, especially in the dual host case, Fast-RTPS mean follows the minima more closely, meaning that the difference between minima and maxima is smaller at all times (the distributions are narrower around the mean).

 

Methodology

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-RTPS publisher in our case) until it is received by a receiver (a Fast-RTPS subscriber). To avoid clock synchronization issues between the systems were publisher and subscriber lie, a common way to approximate latency is by the means of the round-trip time. In this scenario, the publisher sends a message and waits for the subscriber to send it back (much like a ping-pong paradigm), measuring the elapsed time between publisher’s send action to publisher’s receive action. Then, to get a latency approximation, the measured round-trip time is divided by two.

 

 

Testing environment

The experiments have been performed at eProsima’s facilities using two PowerEdge R330 e34s running a Linux 4.15.0-64-generic kernel and Ubuntu 18.04.2 LTS bionic. The specifications of the machines 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: The latest version on Master Repositories on September 17th, 2019

  • Fast RTPS 1.9.x: 010ac53
  • Cyclone DDS: 801c4b1
  • OpenSplice DDS: v6.9 

Tests details

  1. This comparison has been established by performing experiments with the following tools:
    • Fast-RTPS’ LatencyTest
    • CycloneDDS’ Roundtrip example
    • OpenSplice’s ping and pong examples.
  2. The three applications have been configured with the same DDS quality of service (QoS) parameters, which has required to apply a code patch to OpenSplice examples, since the reliability is not configurable.
  3. The experiments have been performed using UDPv4 as transport layer.
  4. The experiments have been performed running both the sender and the reader in the same machine (localhost), and in separate machines connected via ethernet (dual host).
  5. The experiments are performed for 11 different message sizes: 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, and 16384 bytes.
  6. 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 list. For further inquiries about the purpose of each of the parameters please refer to the Fast-RTPS documentation.

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

Further information

For any questions about the methodology used to conduct the experiments, the specifics on how to configure Fast-RTPS or how to patch OpenSplice for replicating these results, 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.