1.1.2. Discovery Performance

This section provides the results of testing Simple Discovery in RTI Connext 7.0.0 in different scenarios, where we modify the number of participants (DomainParticipants) and endpoints (DataWriters and DataReaders).

These numbers should only be used as a first rough approximation, since the results are highly dependent on the hardware, software architecture, QoS in use, data types, and network infrastructure of the system.

1.1.2.1. Time to Complete Discovery (Unicast and Multicast)

The following test measures the time it takes to complete participant discovery as well as endpoint discovery.

To simplify the configuration, we assume the following:

  • Every application in the system runs a single DomainParticipant.

  • There is only one endpoint per DomainParticipant. Every DomainParticipant creates either a DataReader or a DataWriter.

  • There is only one Topic in the system.

  • 50% of the endpoints are DataReaders, 50% are DataWriters.

  • We perform the tests when the entities use Unicast to discover each other and when they use Multicast.

  • All applications are equally distributed across all the available machines for the test.

Note

This scenario is likely not the optimal design solution for a real-life architecture. The purpose of the test is to demonstrate how powerful the Connext discovery protocol is in a flat configuration.

Endpoint Discovery

The following graph displays the time it takes to complete endpoint discovery, per number of participants. There is one endpoint for each participant; across all participants, half the endpoints are DataWriters and half are DataReaders. For each scenario, we graph three values: the maximum, median, and minimum times that the participants took to complete endpoint discovery. (Maximums and minimums are the dashed lines; medians are the solid lines.)

1.1.2.2. Limited Bandwidth Plugin (LBED)

The idea and methodology for this test are similar to the one explained above, except now we use the RTI Limited Bandwidth Plugins to see how much we can decrease bandwidth utilization and speed up the discovery process.

This test requires additional configuration files. For more information, see RTI Limited Bandwidth Plugin User’s Manual.

Note

This scenario is likely not the optimal design solution for a real-life architecture. The purpose of the test is to demonstrate how powerful the Connext discovery protocol is in a flat configuration.

Endpoint Discovery

The following graph displays the time it takes to complete endpoint discovery, per number of participants. There is one endpoint for each participant; across all participants, half the endpoints are DataWriters and half are DataReaders. For each scenario, we graph three values: the maximum, median, and minimum times that the participants took to complete endpoint discovery. (Maximums and minimums are the dashed lines; medians are the solid lines.)

1.1.2.3. Participant Partitions

In this scenario, we test a new feature introduced in RTI Connext 7.0.0: DomainParticipant partitions. For more information, see PARTITION QosPolicy, in the RTI Connext Core Libraries User’s Manual.

Note

This scenario is likely not the optimal design solution for a real-life architecture. The purpose of the test is to demonstrate how powerful the Connext discovery protocol is in a flat configuration.

Endpoint Discovery

The following graph displays the time it takes to complete endpoint discovery, per number of participants. There is one endpoint for each participant; across all participants, half the endpoints are DataWriters and half are DataReaders. For each scenario, we graph three values: the maximum, median, and minimum times that the participants took to complete endpoint discovery. (Maximums and minimums are the dashed lines; medians are the solid lines.)

1.1.2.4. Limiting Interfaces

The idea and methodology for this test are similar to the one explained above. In this case we aim to expore how the network usage (throughput in and out) and the discovery time changes when we announce the participants over more than one interface versus when we limit that announcement to a single interface.

Note

This scenario is likely not the optimal design solution for a real-life architecture. The purpose of the test is to demonstrate how powerful the Connext discovery protocol is in a flat configuration.

Endpoint Discovery

The following graph displays the time it takes to complete endpoint discovery, per number of participants. There is one endpoint for each participant; across all participants, half the endpoints are DataWriters and half are DataReaders. For each scenario, we graph three values: the maximum, median, and minimum times that the participants took to complete endpoint discovery. (Maximums and minimums are the dashed lines; medians are the solid lines.)

1.1.2.5. SPDP2

Note

SPDP2 is an experimental feature in RTI Connext 7.0.0.

The Simple Participant Discovery Protocol 2.0 (SPDP2) is an alternative participant discovery to the Simple Participant Discovery Protocol (SPDP). SPDP2 is meant to improve scalability by reducing the amount of redundant information that is sent during participant discovery and to maintain participant liveliness.

The following graph displays the time it takes to complete endpoint discovery and participant discovery, per number of participants. There is one endpoint for each participant; across all participants, half the endpoints are DataWriters and half are DataReaders. For each scenario, we graph three values: the maximum, median, and minimum times that the participants took to complete endpoint discovery. (Maximums and minimums are the dashed lines; medians are the solid lines.)

Endpoint Discovery Time

Participant Discovery Time