OpenDDS was originally on the 1.0 DDS Specification (formal/04-12-02), but more recent developments are based on the 1.2 DDS Specification (formal/07-01-01).

It offers the following default transport protocols (IPv4 and IPv6):

• TCP/IP
• UDP/IP
• IP multicast

OpenDDS has been found to perform better than other TAO services (notification and real-time event channel) by a factor of two or three. The features offered by the RTEC and NS are similar to DDS, but not identical, so carefully examine your use-cases before choosing one service over another. Speed is not the only criterion.

Performance testing of OpenDDS can be performed using the OpenDDS-Bench performance testing framework. This framework is currently located at:

$DDS_ROOT/performance-tests/Bench

Test setup is done using configuration files. The configuration files for some tests are included in the OpenDDS download file and can be used to repeat the testing reported here in a users environment. This will let users compare existing or other candidate data transport mechanisms in their specific target environment to these results. The test environments include both OCI and customer test labs.

Some testing was performed in the OCI training laboratory. These tests are representative of performance in a busy user driven environment of many desktop hosts with other tasks using the processing and network resources along with the test execution. This leads to noisy results, but demonstrates the performance of OpenDDS under actual, adverse, conditions.

Additional testing was performed on a single multi-core box. This is not likely to be a commonly deployed configuration. The purpose of this test is to establish the baseline behavior of OpenDDS in a non-networked environment. Therefore the latency numbers are those that directly result from the running of the publisher and subscriber, in different threads, on the same box, in loopback mode so as to ensure that the entire transport stack is exercised.

This baseline behavior on a single host can of course be improved by employing shared memory transport and other techniques. So this set of performance characteristics are not as low a latency as OpenDDS can go. This is intended as a reference measurement. For instance, testing with various processor speeds shows that OpenDDS improves in almost a directly proportional manner.

Further testing will be done on boxes with faster processor speeds as they become available to reaffirm this conclusion.

When OpenDDS is added into a more usual networking setting, then additional latency will of course accrue, depending on the network protocol, topology, distance and network hardware etc. In general when measuring the latency in networked settings these other factors may well swamp the baseline results seen here. The testing in the OCI training labs shows that latency might be two to three times greater on a general purpose LAN. (See the actual results of tests performed at OCILab)

Further performance testing will be done on racked systems using the standard protocols supported such as TCP/IP. This is becoming a commonly deployed configuration, for certain types of easily distributed tasks, that require close cooperation. The advertised latency between boxes on "Infinband" for example is a few hundred nanoseconds. (Other rack fabrics offer similar numbers.) Therefore this should not cause much noticeable additional latency. Testing will confirm this.

Comparison of the OpenDDS performance with proprietary offering indicates OpenDDS is the same as the fastest of its competitors. There is no advantage to be gained by purchasing a proprietary implementation.

The bottom line appears to be that when using the open source DDS product, the savings from license fees can be applied to network hardware, racks for co-located systems etc. All these investments will yield a commensurate return.