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 three different use-cases:

  • Unicast + Best Effort reliability

  • Multicast + Best Effort reliability

  • Multicast + Reliable Reliability

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

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 DDS 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.

Detailed Statistics

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

  • Reliable (Multicast)

Subscribers

Sample Size (Bytes)

Avg Mbps

Lost Samples (%)

1

63000

9915.8

0.00

2

63000

9905.6

0.00

4

63000

9915.1

0.00

8

63000

9914.9

0.00

12

63000

9914.9

0.00

24

63000

9910.8

0.00

36

63000

9911.7

0.00

48

63000

9911.8

0.00

60

63000

9903.9

0.00

72

63000

9906.3

0.00

84

63000

9914.8

0.00

96

63000

9946.2

0.00

  • Best Effort (Multicast)

Subscribers

Sample Size (Bytes)

Avg Mbps

Lost Samples (%)

1

63000

9916.2

0.00

2

63000

9915.9

0.00

4

63000

9915.5

0.00

8

63000

9915.5

0.00

12

63000

9915.5

0.00

24

63000

9915.4

0.00

36

63000

9915.5

0.00

48

63000

9915.3

0.00

60

63000

9915.3

0.00

72

63000

9915.4

0.00

84

63000

9915.4

0.00

96

63000

9915.2

0.00

  • Best Effort (Unicast)

Subscribers

Sample Size (Bytes)

Avg Mbps

Lost Samples (%)

1

63000

9916.2

0.00

2

63000

9915.9

0.00

4

63000

9915.5

0.00

8

63000

9915.5

0.00

12

63000

9915.5

0.00

24

63000

9915.4

0.00

36

63000

9915.5

0.00

48

63000

9915.3

0.00

60

63000

9915.3

0.00

72

63000

9915.4

0.00

84

63000

9915.4

0.00

96

63000

9915.2

0.00


Test Hardware

The following hardware was used to perform these tests:

Linux Nodes

Processor: Intel® Xeon® E-2186G 3.8GHz, 12M cache, 6C/12T, turbo (95W)
RAM: 16GB 2666MT/s DDR4 ECC UDIMM
NIC 1: Intel X550 Dual Port 10GbE BASE-T Adapter, PCIe Full Height
NIC 2: Intel Ethernet I350 Dual Port 1GbE BASE-T Adapter, PCIe Low Profile
OS: Ubuntu 18.04 -- gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0

Switch

Dell Networking S4048T-ON, 48x 10GBASE-T and 6x 40GbE QSFP+ ports, IO to PSU air, 2x AC PSU, OS9

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).