UDPv4 Multicast

The following tests have been performed to compare the use of Multicast versus Unicast in a scenario with one Publisher and many Subscribers across several machines connected through 10Gbps NICs to the same LAN.

The tests show five different use cases:

• Unicast + Best Effort reliability

• Unicast + Reliable reliability

• Multicast + Best Effort reliability

• Multicast + Reliable reliability

• Multicast + Reliable reliability + no positive acks

We repeated the tests for sample sizes of 1 kB, 8kB, 63 kB, and 128 bytes.

Linux x64 (10Gbps Network)

63kB, Max Throughput8 kB, Max Throughput1 kB, Max Throughput128 B, Max Throughput

The following graph displays the average Maximum Throughput obtained by all the Subscribers in a scenario where we always start a single RTI Perftest Publisher in a node and we start increasing the number of RTI Perftest Subscribers.

Note

By default, RTI Perftest enables batching when performing a Maximum Throughput test. The batching feature allows sending more than one data sample per RTPS packet, improving network performance for small data sizes. See the RTI Connext Core Libraries User’s Manual for more information on batching.

The batch maximum size is set by RTI Perftest to be 8192 bytes; after 8192 bytes, batching is not enabled.

In some graphs, dashed lines above and below a solid line indicate maximum and minimum throughput values reported by the different Subscribers; the solid line is the median of those values. This range is significant in Best Effort scenarios, where you could have some Subscribers not losing any samples and others losing many; therefore, the median might not show all the information you need. This is not a problem with Reliable reliability, since throughput is ultimately determined by the slowest of all the Subscribers.

Detailed Statistics

The following tables contains the raw numbers presented by RTI Perftest.

• Reliable (Multicast)

Subscribers	Min	Median	90percentile	Max
1	9906.6	9906.6	9906.6	9906.6
2	9915.3	9915.3	9915.3	9915.3
4	9912.9	9912.9	9912.9	9912.9
8	9907.5	9907.6	9907.6	9907.6
10	9914.9	9914.9	9914.9	9914.9
20	9914.8	9914.9	9914.9	9914.9
30	9914.8	9914.9	9914.9	9914.9
50	9888.8	9888.8	9888.9	9888.9
70	9836.0	9836.0	9836.0	9836.0
80	9899.1	9899.1	9899.2	9899.2
90	9914.8	9914.9	9914.9	9914.9
100	9905.3	9905.3	9905.3	9905.4

• Reliable (Multicast) + No Positive Acks

Subscribers	Min	Median	90percentile	Max
1	9915.8	9915.8	9915.8	9915.8
2	9915.2	9915.2	9915.2	9915.2
4	9915.2	9915.2	9915.2	9915.2
8	9914.9	9914.9	9914.9	9915.0
10	9915.0	9915.0	9915.0	9915.0
20	9915.2	9915.2	9915.2	9915.2
30	9902.2	9902.4	9902.5	9902.5
50	9915.2	9915.2	9915.2	9915.2
70	9915.2	9915.2	9915.2	9915.2
80	9915.2	9915.2	9915.2	9915.2
90	9915.2	9915.2	9915.2	9915.2
100	9915.2	9915.2	9915.2	9915.2

• Best Effort (Multicast)

Subscribers	Min	Median	90percentile	Max
1	9916.3	9916.3	9916.3	9916.3
2	9915.7	9915.8	9915.8	9915.8
4	9915.5	9915.5	9915.6	9915.6
8	9915.4	9915.4	9915.4	9915.4
10	9915.3	9915.3	9915.4	9915.4
20	9915.3	9915.4	9915.4	9915.4
30	9915.3	9915.4	9915.4	9915.4
50	9915.3	9915.4	9915.4	9915.4
70	9915.3	9915.3	9915.4	9915.4
80	9915.2	9915.3	9915.3	9915.3
90	9915.3	9915.3	9915.4	9915.4
100	9915.3	9915.3	9915.3	9915.4

• Reliable (Unicast)

Subscribers	Min	Median	90percentile	Max
1	9915.8	9915.8	9915.8	9915.8
2	4640.9	4640.9	4640.9	4640.9
4	2340.9	2340.9	2340.9	2340.9
8	1173.5	1173.5	1173.5	1173.5
10	932.9	932.9	932.9	932.9
20	468.2	468.2	468.3	468.3
30	307.0	307.0	307.0	307.0
50	194.7	194.7	194.8	194.8
70	140.2	140.2	140.2	140.2
80	123.1	123.1	123.1	123.1
90	109.6	109.6	109.6	109.6
100	98.7	98.7	98.7	98.7

• Best Effort (Unicast)

Subscribers	Min	Median	90percentile	Max
1	9916.3	9916.3	9916.3	9916.3
2	4958.1	4958.1	4958.1	4958.1
4	2479.1	2479.1	2479.1	2479.1
8	1239.5	1239.5	1239.5	1239.5
10	991.6	991.6	991.6	991.6
20	495.8	495.8	495.8	495.8
30	330.5	330.6	330.6	330.6
50	198.3	198.3	198.3	198.3
70	141.7	141.7	141.7	141.7
80	124.0	124.0	124.0	124.0
90	110.2	110.2	110.2	110.2
100	99.2	99.2	99.2	99.2

Test Hardware

The following hardware was used to perform these tests:

Linux Nodes

Dell R340 Servers (13 Units)
Processor: Intel Xeon E-2278G (3.4-5GHz, 8c/16t, 16MB cache, 2 memory channels @2666MHz)
RAM: 4x 16GB 2666MHz DIMM (64GB RAM)
HD: 480GB SATA SSD
NIC 1: Intel 710 dual port 10Gbps SFP
OS: Ubuntu 20.04 -- gcc 9.3.0

Switch

Dell 2048 -- 10Gbps switch (10Gbps and 1Gbps interfaces)

From the tests performed above, we can see how Unicast starts with one and two Subscribers, with similar throughput as that produced using Multicast, but when the number of Subscribers increases beyond that, throughput degrades. This is due to having to send each of the samples as many times as there are Subscribers in the test.

When using Multicast, we can see that the performance remains the same when we keep increasing the number of Subscribers, since data is only sent once. This is completely true for Best Effort reliability; however, for Reliable reliability another effect takes place: all samples need to be acknowledged, and the Reliable protocol will send the heartbeat packets via Multicast, but the acknowledge packets that need to be sent in response to a heartbeat are sent via Unicast. This is not a problem when the sample size is relatively big, but it can adversely affect performance when using small sample sizes (such as 128 bytes).

The effect mentioned above about Reliable Multicast scenarios is alleviated by Disabling Positive Acknowledgements When you disable positive acknowledgements, a DataReader will only answer to a DataWriter’s heartbeat if it has samples to reclaim.