![Abstract composition of orange triangles and scattered points on white background (no text or symbols)](.evaluating-vortex-opensplice/3be8d74ad85a0ebb6d644e6f2648736a459f7819700fa7d99fae7f0a34b792fb.jpg) # VORTEX # OPENSPLICE # Evaluation and Benchmarking Guide # Release 6.x # Contents # 1 Preface 1 1.1 About the Evaluation & Benchmarking Guide . . 1.2 Conventions # 2 Introduction 2 # 3 Vortex OpenSplice Basics 3 # 4 Vortex OpenSplice Architectural Modes 4 4.1 The Single Process or Standalone deployment 4 4.2 The Shared Memory or Federated deployment 4 4.3 How to select the Architectural Mode 5 # 5 Vortex OpenSplice Networking Options 7 5.1 How to select the Networking Protocol 7 # 6 Benchmarking OpenSplice: Decision Trees 8 # 7 How to run Vortex OpenSplice 12 7.1 The Vortex OpenSplice Environment 12 7.2 Running Single Process and Shared Memory Modes 12 # 8 Performance Tests and Examples 13 8.1 Round-Trip Latency Performance 13 8.2 Throughput Performance . 14 # 9 Bibliography 16 # 10 Contacts & Notices 17 10.1 Contacts 17 10.2 Notices 17 # 1 # Preface # 1.1 About the Evaluation & Benchmarking Guide The Evaluation & Benchmarking Guide is the starting point for anyone who wants to evaluate Vortex OpenSplice. This Evaluation Guide contains: • a general introduction to ... • descriptions of how to ... • etc. # 1.2 Conventions The icons shown below are used in ADLINK product documentation to help readers to quickly identify information relevant to their specific use of OpenSplice.
IconMeaning
Item of special significance or where caution needs to be taken.
Item contains helpful hint or special information.
WindowsInformation applies to Windows (e.g. XP, 2003, Windows 7) only.
UnixInformation applies to Unix-based systems (e.g. Solaris) only.
LinuxInformation applies to Linux-based systems (e.g. Ubuntu) only.
CC language specific.
C++C++ language specific.
C#C# language specific.
JavaJava language specific.
# 2 # Introduction One of the key differentiators of Vortex OpenSplice is that it provides a user with the ability to choose exactly how to deploy Data Distribution Service (DDS) applications, i.e. there are different DDS system architecture deployment modes and also different networking service protocols. This allows a user to maximize both intranodal and inter-nodal performance based on requirements specific to their own use case. When evaluating Vortex OpenSplice it is very important to understand all of these features and benefits to ensure that the most appropriate combination is evaluated against your specific performance criteria. Once the performance figures have been observed the choice is usually clear. Every customer use case and set of requirements is different, so let us briefly guide you through how to best deploy Vortex OpenSplice so that it meets and exceeds your expectations. Here we explain how easy it is to get started with Vortex OpenSplice and observe the excellent performance and scalability it provides. Vortex OpenSplice is even shipped with dedicated performance tests that the user can build and run easily. Note that this Guide serves only as an introduction and does not replace the full Vortex OpenSplice reference and user guides. # 3 # Vortex OpenSplice Basics Vortex OpenSplice is configured using an XML configuration file. In this file, the user specifies the architectural model and the Vortex OpenSplice services that are to run when the DDS infrastructure is started. The OSPL\_URI environment variable refers to the specific XML configuration file that is used for the current deployment. The default value refers to the ospl.xml file located in the etc/config directory of the Vortex OpenSplice installation. The installation directory itself can be referred to by the OSPL\_HOME environment variable. Please see The Vortex OpenSplice Environment for details of how to set up the Vortex OpenSplice environment. A number of other sample configuration files that can be used when benchmarking Vortex OpenSplice are also provided in the etc/config directory. The OSPL\_URI variable is of the form: ![The image displays a white rectangular box featuring a double border: an outer thin black line and an inner thicker teal line. Inside the box, the word 'Linux' is centered in a bold, black, serif typeface.](.evaluating-vortex-opensplice/0a89b2da44f89cd47baa888b1dc84610f675532c15e254078963599c17075a91.jpg) $\mathtt { O S P L \_ U R I } = \mathtt { f i l e } : / / \mathfrak { H } \mathtt { O S P L \_ H O M E } / \mathtt { e t c } / \mathtt { c o n f i g } / \mathtt { o s p l } . \mathtt { x m l } .$ ![The image displays a rectangular graphic resembling a button or label. It features the text 'Windows' in bold black letters centered on a white background. This text box is enclosed within a thin dark green outer border and a thicker teal inner border.](.evaluating-vortex-opensplice/12fc10cbf4a43dadcaf90c1e6b8836abf921fca36d971d3665a359100923837d.jpg) $\mathtt { O S P L \_ U R I } = \mathtt { U R I } = \mathtt { f i d e } : / / \overset { \circ } { \circ } \mathtt { O S P L \_ H O M E } \overset { \circ } { \circ } \vee \mathtt { e t c } \wedge \mathtt { c o n f i d } \vee \mathtt { o s p l } . \mathtt { x m l } .$ You can refer to the OpenSplice\_DeploymentGuide.pdf later for more details of the OSPL\_URI variable; for now, let us see what aspects of the OpenSplice deployment are controlled by this file. ![The image displays a square icon with a teal background. In the center is a white lowercase letter 'i' with a dot above it.](.evaluating-vortex-opensplice/2681b6800ec05c355026a18b228a1342d523e7e56c3ca384f476c848abdbe594.jpg) The Vortex OpenSplice Launcher tool assists with the selection of the OSPL\_URI variable. There is a Configurations menu that lists the sample configuration files that are available. ![ADLINK\nLeading EDGE COMPUTING\nWelcome\nTools\nControls\nConfigurations\nDocumentation\nExamples\nTuner\nTester\nConfigurator\nRnR Manager\nMemory Statistics\nConsole](.evaluating-vortex-opensplice/79cb97bc8c8fdb0c723caca7ae98559a817f7d162d724de7486c1875bc622025.jpg) Figure 3.1: The Launcher tool The Vortex OpenSplice Launcher tool is also able to run the examples and performance tests that are described later in this document. # 4 # Vortex OpenSplice Architectural Modes Vortex OpenSplice provides two main architectural modes. These are the Single Process deployment mode, which provides a Standalone architecture, and, unique to OpenSplice, the Shared Memory deployment mode which provides a Federated architecture. # 4.1 The Single Process or Standalone deployment Features of this mode are: • Simplest to run and get started with. • Each DDS application process contains the entire DDS infrastructure. • Uses in-process heap memory for the DDS database. • Vortex OpenSplice services run as threads within the application process. • When there are multiple DDS application processes on a single machine, the communication between them must be done via a networking service; this introduces additional overhead so performance in this scenario is not optimal. ![This block diagram illustrates a system architecture with the following labeled blocks and connections:\n\n* **Top Level:** A red hexagon is positioned at the top. A grey box labeled **'DDS Application Process'** points to this hexagon via an arrow.\n* **Middle Level:** Directly below is a large grey rectangle labeled **'In-Process Heap Memory'**.\n* **Service Layer:** Connected to the bottom of the memory block by vertical lines are three grey hexagons:\n * **'OpenSplice Daemon'**\n * **'Networking Service'**\n * **'Durability Service'**\n* **Thread Association:** A grey box labeled **'OpenSplice Service Threads'** is positioned to the right, with an arrow pointing towards the three service hexagons.\n* **Network Interface:** A red dotted vertical line connects the **'Networking Service'** hexagon downwards to a long grey bar at the bottom labeled **'Physical Network'**.](.evaluating-vortex-opensplice/1a60c8b3017bbd07ef16a57b03b35e2dc90c03e5ef9f195b4d49a9d114daf873.jpg) Figure 4.1: Single Process or Standalone deployment # 4.2 The Shared Memory or Federated deployment Features of this mode are: • The DDS infrastructure is started once per machine. • Uses shared memory for the DDS database. • Each DDS application process interfaces with the shared memory rather than creating the DDS infrastructure itself. • Allows the data to be physically present only once on any machine. • Reading and writing directly to locally-mapped memory is far more efficient than having to actually move the data via a networking service, allowing for improved performance and scalability. • Vortex OpenSplice services are able to arbitrate over all of the DDS data on the node, and so can make smart decisions with respect to data delivery so that priority QoS values (for example) are respected; this is not possible when there are multiple standalone deployments on a machine. ![This diagram illustrates a system architecture with the following labeled blocks and connections:\n\n**Labeled Blocks:**\n* **Top:** Four red hexagons arranged horizontally.\n* **Center:** A large rectangular block labeled '**Shared Memory**'.\n* **Bottom Services:** Three grey hexagons arranged horizontally, labeled from left to right as '**OpenSplice Daemon**', '**Networking Service**', and '**Durability Service**'.\n* **Bottom Layer:** A long horizontal bar at the very bottom labeled '**Physical Network**'.\n\n**Annotations (Right Side):**\n* A bracket points to the red hexagons labeled '**DDS Application Processes**'.\n* A bracket points to the Shared Memory block labeled '**DDS Infrastructure**'.\n* A bracket points to the three bottom service hexagons labeled '**OpenSplice Service Processes**'.\n\n**Connections:**\n* Solid vertical lines connect each of the four red hexagons down to the '**Shared Memory**' block.\n* Solid vertical lines connect the '**Shared Memory**' block down to each of the three service hexagons (**'OpenSplice Daemon'**, '**Networking Service**', and '**Durability Service'**).\n* A red dashed vertical line connects the '**Networking Service**' hexagon down to the '**Physical Network**' bar.](.evaluating-vortex-opensplice/e4b6e93c7b304b8fadbf4c3fab766c12596ea0fb504a93b6b7da928ee134753d.jpg) Figure 4.2: Shared Memory or Federated deployment When there are multiple DDS applications running on a single computing node, the use of OpenSplice’s unique Shared Memory architecture can provide greater performance, smaller footprint and better scalability than other DDS deployment options. # 4.3 How to select the Architectural Mode • For a Single Process deployment, set the OSPL\_URI variable to refer to a single process (sp) xml file such as ospl\_sp\_ddsi.xml or ospl\_sp\_nativeRT.xml. Note that a networking service (such as ddsi or nativeRT) is required for two DDS application processes to communicate even if they are running on the same physical machine. See the next section for more details on networking options. A single process deployment is enabled when the Domain section of the XML configuration contains a ‘<SingleProcess> TRUE’ attribute. NOTE for VxWorks kernel mode builds of OpenSplice the single process feature of the OpenSplice domain must not be enabled. i.e. “<SingleProcess>true</SingleProcess>” must not be included in the OpenSplice Configuration xml. The model used on VxWorks kernel builds is always that an area of kernel memory is allocated to store the domain database ( the size of which is controlled by the size option in the Database configuration for opensplice as is used on other platforms for the shared memory model. ) This can then be accessed by any task on the same VxWorks node. • For a Shared Memory deployment, set the OSPL\_URI variable to refer to a shared memory (shmem) xml file such as ospl\_shmem\_no\_network.xml, ospl\_shmem\_ddsi.xml, or ospl\_shmem\_nativeRT.xml. Note that two or more DDS applications running on the same physical machine are able to communicate via the shared memory so a networking service (such as ddsi or nativeRT) is not necessarily required. A shared memory deployment is enabled when the Domain section of the XML configuration does not contain a ‘<SingleProcess> TRUE’ attribute but does contain a ‘<Database>’ attribute. Note that by default the OSPL\_URI environment variable refers to a Single Process configuration, so to see the extra performance and scalability benefits of Vortex OpenSplice’s Shared Memory architecture it is necessary to switch from the default. # 5 # Vortex OpenSplice Networking Options Vortex OpenSplice provides several networking options for the delivery of DDS data between nodes. The networking service selection is largely transparent to the user; the difference is observed in the CPU consumption, networking load, and ultimately how fast and efficiently the data is delivered between nodes. The most applicable service is dependent on the requirements of the use case. Vortex OpenSplice DDSI is the industry standard protocol providing vendor interoperability that operates using a typed ‘pull’ style model. Vortex OpenSplice RTNetworking is an alternative to the DDSI wire protocol. RTNetworking uses a type-less ‘push’ style model in contrast to DDSI and is often the more performant, scalable option. RTNetworking also offers prioritization of network traffic via ‘channels’, partitioning to separate data flows and optional compression for low-bandwidth environments. Vortex OpenSplice SecureRTNetworking provides these features together with encryption and access control. Vortex OpenSplice DDSI2E is the ‘enhanced’ version of the interoperable service. DDSI2E offers the benefits of the DDSI protocol (such as its automatic unicast delivery in the case of there being a single subscribing endpoint), together with some of the performance features of the RTNetworking service such as channels, partitioning and encryption. # 5.1 How to select the Networking Protocol As with the architectural deployment choice, the selection of the networking service is described by the XML configuration file. Note that this choice is independent of and orthogonal to the architectural deployment: you can have single process or shared memory with any of the networking service protocols. • To run with a DDSI service, set the OSPL\_URIvariable to refer to a DDSI xml file such as ospl\_sp\_ddsi.xml or ospl\_shmem\_ddsi.xml. • To run with an RTNetworking service, set the OSPL\_URI variable to refer to an RTNetworking xml file such as ospl\_sp\_nativeRT.xml or ospl\_shmem\_nativeRT.xml. • To run with a SecureRTNetworking service, set the OSPL\_URIvariable to refer to the ospl\_shem\_secure\_nativeRT.xml SecureRTNetworking xml file. • To run with a DDSI2E deployment, set the OSPL\_URI variable to refer to a DDSI2E xml file such as ospl\_sp\_ddsi2e.xml or ospl\_shmem\_ddsi2e.xml. ![The image displays a standard warning symbol. It features a red triangle with rounded corners enclosing a black exclamation mark in the center, set against a white background.](.evaluating-vortex-opensplice/9130b92904c8e0d42bbe4a94cd55d24babc2442238e9a0b385f7a930350e13a5.jpg) Note that by default, the OSPL\_URI environment variable refers to a DDSI configuration, so to see the extra performance and scalability benefits of Vortex OpenSplice’s RTNetworking or DDSI2E it is necessary to switch from the default. # 6 # Benchmarking OpenSplice: Decision Trees DDS provides many functional benefits that set it apart from other middleware technologies, but users often still have specific performance requirements for latency, throughput, CPU and network utilization. Vortex OpenSplice provides the functional benefits of the technology whilst remaining committed to excellent performance. The flowcharts in this chapter show the decision criteria that may be applied in order to decide on the most appropriate test case, architectural mode, and networking protocol options for your specific use case and requirements. . How to run Vortex OpenSplice: ![The flowchart begins with a 'Start' block leading to a 'Choose benchmark program' block. This flows into a decision diamond labeled 'Latency?'.\n\n- From 'Latency?', an arrow labeled 'No' points left to a block 'Select throughput test program'.\n- An arrow labeled 'Yes' points right to a block 'Select latency test program'.\n- Both test program blocks have arrows pointing down to a central block labeled 'Choose programming language'.\n\nFrom 'Choose programming language', the flow proceeds downward to a diamond labeled 'Java'.\n- To the right of this diamond is the text 'For Java environments'.\n- An arrow labeled 'No' points downward to a diamond labeled 'DCPS C++'.\n- To the right of the 'DCPS C++' diamond is the text 'Best C++ performance'.\n- An arrow labeled 'Yes' points left, and an arrow labeled 'No' points downward to a diamond labeled 'ISO C++'.\n- To the right of the 'ISO C++' diamond is the text 'For ease of use'.\n- An arrow labeled 'Yes' points left, and an arrow labeled 'No' points downward to a diamond labeled 'C'.\n- To the right of the 'C' diamond is the text 'For max performance'.\n- An arrow labeled 'Yes' points left, and an arrow labeled 'No' points downward to a diamond labeled 'C#'.\n- To the right of the 'C#' diamond is the text 'For C# environments'.\n- An arrow labeled 'Yes' points left to a circle labeled '2'.\n\nAll the left-pointing arrows from the language diamonds (Java, DCPS C++, ISO C++, and C) converge onto a vertical line on the left side that leads down to the circle '2'.](.evaluating-vortex-opensplice/7cb4200b1298d31395b102a3ea7be57d294f99dd18fb46fd4f0486961a8c9d7e.jpg) Figure 6.1: Selecting a specific performance test and programming language ![The flowchart begins at node **2** and flows downward to a process block labeled **Choose deployment mode**.\n\nFrom there, the path continues to a decision diamond: **Multiple nodes, 1 application per node?**.\n* **Yes**: Leads left to a process block **Use OSPL-SP-XXX**.\n* **No**: Leads down to a second decision diamond: **Multiple nodes, multiple applications per node?**.\n\nFrom this second decision:\n* **Yes**: Leads left to a process block **Use OSPL-shmem-XXX**.\n* **No**: Leads down to a third decision diamond: **Single node multiple applications?**.\n\nFrom this third decision:\n* **Yes**: Leads left to a process block **Use OSPL-shmem-no-network**.\n* **No**: Leads down to a final decision diamond: **Single node 1 application**.\n\nFrom this final decision:\n* **Yes**: Leads left to a process block **Use OSPL-SP-XXX**.\n\nFinally, arrows from all four 'Use...' process blocks point to the left, merging into a single vertical line that leads down to the end node **3**.](.evaluating-vortex-opensplice/bf86f2f8e5cad3d702fa7df36d1c10b31475caf949c9518707d97466fd81943e.jpg) Figure 6.2: Selecting the architectural deployment mode ![The flowchart begins with a circle labeled **3** pointing downward to a rectangle labeled **Choose networking protocol**. This leads to a diamond decision block labeled **Do you need vendor interoperability?**.\n\nFrom this decision block:\n* The path labeled **Yes** points left to a rectangle labeled **DDSI**.\n* The path labeled **No** points downward to a rectangle labeled **RTNetworking** (with the text **For max performance** next to it).\n\nFollowing the **DDSI** path:\n* An arrow points left to a diamond labeled **Are secure network partitions required?**.\n * The path labeled **Yes** points downward to a rectangle labeled **Use OSPL-XXX-ddsi2e.xml**.\n * The path labeled **No** points downward to a rectangle labeled **Use OSPL-XXX-ddsi.xml**.\n\nFollowing the **RTNetworking** path:\n* An arrow points downward to a diamond labeled **Are secure network partitions required?**.\n * The path labeled **Yes** points left to a rectangle labeled **Use OSPL-XXX-secure_nativeRT.xml**.\n * The path labeled **No** points downward to a rectangle labeled **Use OSPL-XXX-nativeRT.xml**.\n\nFinally, arrows from **Use OSPL-XXX-ddsi2e.xml**, **Use OSPL-XXX-ddsi.xml**, **Use OSPL-XXX-secure_nativeRT.xml**, and **Use OSPL-XXX-nativeRT.xml** all converge and point to a rounded rectangle at the bottom labeled **End**.](.evaluating-vortex-opensplice/cff8884515f261bc705278aeec5244ed8c673d4c8793bc816d4f455476b6ed00.jpg) Figure 6.3: Selecting the network protocol options # 7 # How to run Vortex OpenSplice # 7.1 The Vortex OpenSplice Environment A release file is provided with the Vortex OpenSplice installation which contains the environment variables that are required. Create an Vortex OpenSplice environment as follows. # First: # Linux Open a shell and source the release.com file from the Vortex OpenSplice installation directory. # Windows Open a Windows Command prompt and run the release.bat file in the Vortex OpenSplice installation directory. # Windows Alternatively, use the Vortex OpenSplice Command Prompt that can be accessed from the Windows Start menu (this will implicitly run release.bat). Note that the Vortex OpenSplice Launcher tool also provides a Console option which sets up the Vortex OpenSplice environment. # Next: Set the OSPL\_URI variable to refer to the Vortex OpenSplice configuration that is required (see the section How to select the Architectural Mode). # 7.2 Running Single Process and Shared Memory Modes • With an OSPL\_URI variable referring to a Single Process deployment, you just need to start the DDS application process. The create\_participant() operation, which is the entry into the DDS Domain, will create the entire DDS infrastructure within the application process and the services will be started as threads. • With an OSPL\_URI variable referring to a Shared Memory deployment, it is necessary to start the DDS infrastructure before starting your DDS application processes. That is done by using the ospl utility tool: ```txt ospl start # now run the DDS application processes as normal ospl stop ``` # 8 # Performance Tests and Examples To make the evaluation process as easy as possible, Vortex OpenSplice is shipped with dedicated performance tests that can be used to measure latency and throughput. The tests are simple and clear, allowing the user to obtain performance results easily. The easiest way to build and run the performance tests is to use the Vortex OpenSplice Launcher tool. In the Examples menu select the specific example and the appropriate language and configuration. Click the Compile Example button and then Run Example. This will run the DDS applications, and if running with a shared memory configuration it will also manage the starting and stopping of Vortex OpenSplice. Vortex OpenSplice also provides dedicated performance testing scripts which: • Test multiple API bindings • Use a varying range of payload sizes • Timestamp and append results to a CSV file • Set process priority and CPU affinity Please see the html files for the individual performance tests for details of how to run these scripts. # 8.1 Round-Trip Latency Performance The latency of a DDS implementation is an expression of how fast data can be delivered between two DDS applications. Round-trip latency is the time taken for an individual DDS data sample to be delivered from Application A to Application B and back again, so importantly it includes metrics for both data delivery and reception. The easiest way to build and run the performance tests is to use the Vortex OpenSplice Launcher tool as explained above. Alternatively, to manually build and run the round-trip performance test, for example for the ISO C++ API: # Linux ```shell # In an Vortex OpenSplice environment: cd $OSPL_HOME/examples/dcps/RoundTrip/isocpp make cd $OSPL_HOME/examples/dcps/RoundTrip/isocpp # If using shared memory do "ospl start" ./pong # If using shared memory do "ospl stop" # In another Vortex OpenSplice environment: cd $OSPL_HOME/examples/dcps/RoundTrip/isocpp # If using shared memory do "ospl start" ./ping 20 100 # If using shared memory do "ospl stop" ``` # Windows ```powershell # Load the Vortex OpenSplice examples project solution # into Visual Studio and build the required projects # In an Vortex OpenSplice environment: cd %OSPL_HOME%\examples\dcps\RoundTrip\isocpp # If using shared memory do "ospl start" pong.exe # If using shared memory do "ospl stop" # In another Vortex OpenSplice environment: cd %OSPL_HOME%\examples\dcps\RoundTrip\isocpp # If using shared memory do "ospl start" ping.exe 20 100 # If using shared memory do "ospl stop" ``` The ping application will report the roundtrip time taken to send DDS data samples back and forth between the applications. The test utilizes the ReliabilityQoS set to RELIABLE by default in order to show the maximal performance whilst maintaining the guaranteed delivery of DDS samples. See the README file for the test for further details. # The lowest roundtrip latency may be achieved by tuning the test parameters appropriately. As mentioned above, the performance testing script described in the html for the example is a convenient way to test and record the running of this test. ![The image displays a standard warning sign consisting of a red equilateral triangle with a thick border and rounded corners. Inside the triangle, against a white background, is a large black exclamation point centered in the middle.](.evaluating-vortex-opensplice/cdb453c90c5d20ea1f58b071e361d55a149335cb9d37e203b4645e8ba48605ac.jpg) Note that the default OSPL\_URI value refers to a Single Process deployment with DDSI networking. • To observe the best performance within a node it is suggested that you use a Shared Memory configuration. • To observe the best performance between nodes it is suggested that you use an RTNetworking service configuration. # 8.2 Throughput Performance The throughput of a DDS implementation is an expression of the rate of data delivery through the DDS system. Measured in bits per second, it describes the ability of the DDS implementation to effectively deliver DDS data without data loss. As with the round-trip test, the easiest way to build and run the throughput performance test is to use the Vortex OpenSplice Launcher tool. Alternatively, to manually build and run the throughput performance test, for example for the ISO C++ API: # Linux ```shell # In an Vortex OpenSplice environment: cd $OSPL_HOME/examples/dcps/Throughput/isocpp make cd $OSPL_HOME/examples/dcps/Throughput/isocpp # If using shared memory do "ospl start" ./publisher # If using shared memory do "ospl stop" # In another In an Vortex OpenSplice environment: cd $OSPL_HOME/examples/dcps/Throughput/isocpp # If using shared memory do "ospl start" ./subscriber # If using shared memory do "ospl stop" ``` # Windows ```powershell # Load the Vortex OpenSplice examples project solution # into Visual Studio and build the required projects # In an Vortex OpenSplice environment: cd %OSPL_HOME%\examples\dcps\Throughput\isocpp # If using shared memory do "ospl start" publisher.exe # If using shared memory do "ospl stop" # In another Vortex OpenSplice environment: cd %OSPL_HOME%\examples\dcps\Throughput\isocpp # If using shared memory do "ospl start" subscriber.exe # If using shared memory do "ospl stop" ``` The subscriber application will report the DDS data throughput by default once per second. This and many other aspects of the test can be configured on the command line. The test utilizes the ‘ReliabilityQoS set to RELIABLE by default in order to show the maximal performance whilst maintaining the guaranteed delivery of DDS samples. See the README file for the test for further details. # The maximum throughput may be achieved by tuning the test parameters appropriately. As mentioned above, the performance testing script described in the html for the example is a convenient way to test and record the running of this test. ![The image displays a triangular warning sign with a thick red border and a white interior, featuring a black exclamation mark in the center.](.evaluating-vortex-opensplice/a5a4ad060b5f0582a684afae8855c47d307eda09c31b8e7e822d3c775dbdac7c.jpg) Note that the default OSPL\_URI value refers to a Single Process deployment with DDSI networking. • To observe the best performance within a node it is suggested that you use a Shared Memory configuration. • To observe the best performance between nodes it is suggested that you use an RTNetworking service configuration. # 8.2.1 Achieving Maximum Throughput Where there is a requirement to support continuous flows or ‘streams’ of data with minimal overhead consider the use of Vortex OpenSplice Streams. The ability to deliver potentially millions of samples per second is realized by the Streams feature transparently batching (packing and queuing) the periodic samples. ![Based on the provided image, here is an accurate and concise description of the flowchart:\n\n**Labeled Blocks:**\n* **Top Left:** Text 'High Frequency Samples' and a vertical stack of five grey rounded rectangles.\n* **Middle Left:** A red rounded rectangle labeled 'StreamDataWriter'.\n* **Bottom Left:** Text 'Batching' and a vertical stack of three grey rounded rectangles inside a dashed border. To the left of this stack is the text 'Temporal or Samples-Count Driven Batching'.\n* **Middle Right:** A red rounded rectangle labeled 'StreamDataReader'.\n* **Bottom Right:** Text 'Un-Batching' and a vertical stack of three grey rounded rectangles inside a dashed border.\n* **Top Right:** Text 'High Frequency Samples' and a vertical stack of five grey rounded rectangles.\n\n**Connections:**\n* A red arrow points downward from the 'High Frequency Samples' text to the top-left stack of rectangles.\n* A thick black arrow points upward from the bottom-left stack into the 'StreamDataWriter' block.\n* A thick black horizontal line connects the bottom-left stack to the bottom-right stack.\n* A thick black arrow points upward from the bottom-right stack into the 'StreamDataReader' block.\n* A red arrow points upward from the top-right stack to the 'High Frequency Samples' text.](.evaluating-vortex-opensplice/d71071aadcb09644de594b04540ac6c92f3dc6b9de5f1ec5fde017c0eb959c55.jpg) Figure 8.1: Streams Architecture The streams performance example is located in the examples/streams directory within the installation. # 9 # Bibliography # OMG DDS 1.2 Object Management Group, ‘Data Distribution Service for Real-Time Systems Version 1.2’, Available specification formal/07-01-01 # OMG DDS 1.4 Object Management Group, ‘Data Distribution Service for Real-Time Systems Version 1.4’, Available specification formal/15-04-10 # OMG DDSI 2.1 Object Management Group, ‘The Real-Time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol Specification Version 2.1’, Document Number: formal/2009-01-05 # OMG DDSI 2.2 Object Management Group, ‘The Real-Time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol Specification Version 2.2’, Document Number: formal/2014-09-01 # OMG DDS XTYPES 1.0 Object Management Group, ‘Extensible and Dynamic Topic Types for DDS Version 1.0’, Document Number: formal/2012-11-10 # 10 # Contacts & Notices # 10.1 Contacts # ADLINK Technology Corporation 400 TradeCenter Suite 5900 Woburn, MA 01801 USA Tel: +1 781 569 5819 # ADLINK Technology Limited The Edge 5th Avenue Team Valley Gateshead NE11 0XA UK Tel: +44 (0)191 497 9900 # ADLINK Technology SARL 28 rue Jean Rostand 91400 Orsay France Tel: +33 (1) 69 015354 Web: http://ist.adlinktech.com/ Contact: http://ist.adlinktech.com E-mail: ist\_info@adlinktech.com LinkedIn: https://www.linkedin.com/company/79111/ Twitter: https://twitter.com/ADLINKTech\_usa Facebook: https://www.facebook.com/ADLINKTECH # 10.2 Notices Copyright © 2018 ADLINK Technology Limited. All rights reserved. This document may be reproduced in whole but not in part. The information contained in this document is subject to change without notice and is made available in good faith without liability on the part of ADLINK Technology Limited. All trademarks acknowledged. [🔗 Link to the original document](.evaluating-vortex-opensplice/evaluating-vortex-opensplice.pdf)