•  
  •  

These performance statistics were performed using two to four computers with the following characteristics:

  • Intel Core i3 @3.4GHz
  • 4GB RAM
  • Intel Gigabit Network adapter at 1Gbps

Two different types of tests have been carried out: Latency and Throughput tests. The following list contains direct access to each of the tests and its results. 

Latency

The latency is usually defined as the amount of time a message takes to traverse a system. In a packet-based network the latency is usually measured either as the one-way latency (the time from the source sending the packet to the destination receiving it) or as the round-trip delay time (the time from source to destination plus the time from the destination back to the source). The latter is more often used since it can be measured from a single point.

In the case of an RTPS communication exchange the latency could be defined as the time it takes a publisher to serialize and send a data message plus the time it takes a matching subscriber to receive and de-serialize it. Applying the same round-trip concept mentioned before, the round-trip latency could be defined as the time it takes a message to be sent by a publisher, received by a subscriber and sent back to the same publisher. For example, in the figure below the round-trip time would be T2-T1 making the latency (T2-T1)/2.

RTPS Latency measurement

In a multiple subscriber scenario, the measured latency is obtained in a similar matter. In this case the publisher sends the data to both subscribers but only one responds to the message. In a similar way, the latency is also obtained as (T2-T1)/2.

RTPS latency with eProsima Fast RTPS

 

Latency performance on Linux

These tests were carried using Fedora 20 64bit on the computers described at the beginning of the article. In all Latency tests 10.000 samples were sent from the publisher to the subscribers and back and the mean time was calculated. 

 

One subscriber Latency

The obtained values for the one subscriber case are presented below:

eProsima Fast RTPS latency 1 to 1 linux

The plot shows that the latency increases linearly with the payload size with a very small slope. It is also interesting to show the evolution of the latency for smaller values of the message size. Although included in the plot these values cannot be easily appreciated. The following graph presents the latency for the same case but only for message size varying between 16 and 1024 bytes.

eProsima Fast RTPS latency 1 to 1 linux close up

It can be observed that the latency remains stable around 90 - 100 μs for message sizes varying between 16 and 512 bytes. For 1024 bytes a small increase in latency can be observed, although very small compared to the increment in the message size. 

 

Multiple subscribers Latency

This test was carried out with one publisher and three subscribers listening to the same multicast IP. Each latency test was carried out multiple times, sending 10.000 samples of varying message sizes. The results obtained for this case can be observed below:

eProsima-Fast-RTPS-latency-1-to-3-linux

The plot shows that the latency is almost identical to the one subscriber case. The use of a very efficient implementation combined with the multicast broadcast of the data makes eProsima Fast RTPS very efficient when transmitting large amounts of information to multiple subscribers. The close up view of the three subscribers case is shown below:

eProsima-Fast-RTPS-latency-1-to-3-linux-close-up The close up view of the latency for the three subscribers case shows that even for three subscribers the latency remains very stable for small message sizes (around 100 μs).

 

Latency performance on Windows

These tests were carried out with the aforementioned computers running a Windows 7 64 bit OS. Each latency test consists of 10.000 samples of varying size being exchanged between the publisher and the subscribers. The values shown in these plots are the mean latencies obtained between multiple runs of each test.

 

One subscriber Latency

In this case a single publisher sends a message to a single subscriber, which then returns it. The mean latency for the one subscriber case results can be observed below:

eProsima-Fast-RTPS-latency-1-to-1-windowsFor windows we observe a very similar behavior to the tests carried out in Linux. Although the latency starts at slightly larger values for small message sizes (around 150 μs) the evolution with the message size is still linear and with a very small slope. Repeating the closeup view we provided in the Linux test we obtain the following graph.

eProsima-Fast-RTPS-latency-1-to-1-windows-close-up

The plot shows that the latency remains stable around 155 μs for message sizes varying between 16 and 1024 bytes. 

 

Multiple subscribers Latency

This test was carried out with one publisher and three subscribers listening to the same multicast IP. The configuration of the test was similar to the previous ones. Multiple runs of 10.000 samples exchange for different message sizes were performed. The mean values for the latency are shown below:

eProsima-Fast-RTPS-latency-1-to-3-windows

Again we can observe that cost of having multiple subscribers is almost negligible with respect to the one subscriber case. The latency still increases linearly with the message size with a very small slope. A close up view of the latency for this case is shown below:

eProsima-Fast-RTPS-latency-1-to-3-windows-close-up

This graph shows that the latency remains stable around a specific value (190 μs) for message sizes varying between 16 and 1024 bytes. 

 

Throughput

In communication networks the throughput is usually defined as the rate of successful message delivery over a communication channel. The throughput is usually expressed in bytes per second. There are different methods to measure the throughput of a communication network. The most common ones are to send a large file (or multiple smaller ones) and measure the time that takes to transmit it to another point of the network and afterward divide the amount of data by the time it took to send it.

In the case of an RTPS communication, the throughput can be measured sending groups of messages in a certain amount of time and the obtaining the combined size of the transmitted data. However, to obtain the maximum throughput value, different message demands (D - the number of continuous messages send) must be tried in order to find the best value; i.e., one that maximizes the available send pipe in the publisher without overflowing the receive queue in the subscriber (producing packet losses). A diagram showing the process followed to perform this test is shown next:

eProsima Throughput Schema for RTPS

Of course the throughput can be measured both at the publisher side (how much data you send) and at the subscriber side (how much data you receive). If no packets are lost the values will be very similar and the slight difference in the values will be caused by differences in time measurement. However, if packets are lost the throughput values will be different depending on the side. To establish a sound measurement rule we will assume that the maximum throughput for each message size will be the one measured in the publisher side provided that no packet loss is experienced in the subscriber side.

 

Throughput performance on Linux

Multiple demands and message sizes were tried to obtain the evolution of the throughput with the message size. In these tests a single publisher sent data messages to a single subscriber over a single RTPS topic. These results are shown in the following plot.

eProsima Fast RTPS Throughput performance on Linux

The plot clearly shows an asymptotic behavior of the throughput with the message size. A sustainable large throughput value is obtained using the Fast RTPS implementation. Throughput values larger than 600MBits/sec are obtained with messages from 1024 bytes. The maximum throughput value obtained remains stable around 950MBits/sec when the message size increases, meaning that we can take advantage of about a 95% of the available bandwidth. Since Fast RTPS sends messages directly between the publisher and the subscriber, without needing any centralized server, our library does not impose any limit in the amount of data that can be transmitted. As shown in the plot, the limit comes from the network adapter.

 

Throughput performance on Windows

Repeating the throughput experiment using a Windows 7 64bit SO the obtained results are:

eProsima Fast RTPS Throughput performance on Windows

The results are very similar to the ones obtained on Linux. A maximum throughput value of 950Mbits/s is also obtained with large message sizes. It should be noted that on Windows 7 an alteration to the registry was needed in order to achieve the expected throughput in message sizes larger than 1024. The key FastSendDatagramThreshold located under the registry path: "HKLM\System\CurrentControlSet\Services\Afd\Parameters" should be set to higher values than the default 1024 bytes. This key determines whether a datagram should go through the fast I/O path or should be buffered during a send operation. For out tests this value was set to 2048 bytes.

RTPS Opensource solution

For further information about eProsima Fast RTPS