Content-Filtered Topics

The following tests have been performed to show the benefits of using Content-Filtered Topics (CFT) in your system design. For more information about this feature, see the following section in the RTI Connext DDS Core Libraries User’s Manual.

In this set of scenarios we will communicate an RTI Perftest Publisher application with several RTI Perftest Subscribers distributed across several machines in the same LAN network. Communication is done through UDPv4. The idea for the scenario is that only one Subscriber from all of them is interested in each sample at a time (we do this in a Round-Robin fashion).

The three different approaches we will test are the following ones:

  • Using Unicast: Sample are sent by the publisher individually through Unicast. All samples are received by all Subscribers and then they discard them if they are not interested. This could be the approach followed in an initial design of a system.

  • Using Multicast: First level of improvement, samples are only sent once, however all the Subscriber will need to receive and process them (only to discard them at the end).

  • Using Unicast and CFT: The benefit of using Content-Filtered Topics is that in most cases it can be performed at the Writer Side (See this section in the Connext DDS Core Libraries User’s Manual to see the conditions). Hence, samples are sent via Unicast only to the subscriber that is interested in them (that information is known through the Filter query of the CFT). That way we minimize the processing in each Subscriber and we save Bandwidth.

See below the results of performing these test for Keyed samples of 1 kB.

The graph below shows the one-way latency for the use-cases mentioned above for best-effort as well as strict reliable reliability scenarios.

Note

We use the median (50th percentile) instead of the average in order to get a more stable measurement that does not account for spurious outliers.

Note

In cases where the Latency has to be measured between an RTI Perftest Publisher and multiple RTI Perftest Subscribers, each latency sample is assigned by the Publisher to be answered by a different Subscriber (and not by any other) in a Round-Robin fashion.

Detailed Statistics

This table contains the raw numbers presented by RTI Perftest.

  • CFT, Best Effort

Subscribers

Size

Average Latency

1

1024

26

2

1024

26

4

1024

23

8

1024

25

12

1024

25

24

1024

24

48

1024

26

96

1024

24

120

1024

25

196

1024

28

  • CFT, Reliable

Subscribers

Size

Average Latency

1

1024

26

2

1024

24

4

1024

24

8

1024

23

12

1024

23

24

1024

24

48

1024

25

96

1024

27

120

1024

28

196

1024

30

  • Multicast, Best Effort

Subscribers

Size

Average Latency

1

1024

26

2

1024

25

4

1024

26

8

1024

26

12

1024

25

24

1024

26

48

1024

25

96

1024

25

120

1024

25

196

1024

26

  • Multicast, Reliable

Subscribers

Size

Average Latency

1

1024

26

2

1024

26

4

1024

26

8

1024

25

12

1024

24

24

1024

24

48

1024

24

96

1024

25

120

1024

25

196

1024

28

  • Unicast, Best Effort

Subscribers

Size

Average Latency

1

1024

26

2

1024

27

4

1024

23

8

1024

28

12

1024

27

24

1024

29

48

1024

40

96

1024

61

120

1024

72

196

1024

103

  • Unicast, Reliable

Subscribers

Size

Average Latency

1

1024

24

2

1024

24

4

1024

24

8

1024

25

12

1024

26

24

1024

34

48

1024

51

96

1024

76

120

1024

92

196

1024

136


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