No description
Find a file
Erik Boasson baadb2b690 remove legacy configuration settings
These settings all constitute settings from the long history of the DDSI
stack predating Eclipse Cyclone DDS and can reasonably be presumed never
to have been used in Cyclone.  Their removal is therefore not expected
to break backwards compatibility (which would be anyway be limited to
Cyclone complaining about undefined settings at startup):

* Tracing/Timestamps[@absolute]: has always been ignored

* Tracing/Timestamps: has always been ignored

* General/EnableLoopback: ignored for quite some time, before that
  changing it from the default resulted in crashes.

* General/StartupModeDuration: it did what it advertised (retain data in
  the history caches of volatile writers as-if they were transient-local
  with a durability history setting of keep-last 1 for the first few
  seconds after startup of the DDSI stack) but had no purpose other than
  complicating things as the volatile readers ignored the data anyway.

* General/StartupModeCoversTransient: see previous -- and besides,
  transient data is not supported yet in Cyclone.

* Compatibility/RespondToRtiInitZeroAckWithInvalidHeartbeat: arguably a
  good setting given that DDSI < 2.3 explicitly requires that all
  HEARTBEAT messages sent by a writer advertise the existence of at least
  1 sample, but this has been fixed in DDSI 2.3.  As this requirement was
  never respected by most DDSI implementations, there is no point in
  retaining the setting, while it does remove a rather tricky problem
  immediately after writer startup involving the conjuring up of a
  sample that was annihilated immediately before it could have been
  observed.

  That conjuring up (as it turns out) can cause a malformed message to go
  out (one that is harmless in itself).  Fixing the generation of that
  malformed message while the entire point of the trick is moot in DDSI
  2.3 is a bit silly.

  Note that full DDSI 2.3 compliance needs a bit more work, so not
  bumping the DDSI protocol version number yet.

* Compatibility/AckNackNumbitsEmptySet: changing it from 0 breaks
  compatibility with (at least) RTI Connext, and its reason for
  existence disappers with a fix in DDSI 2.3.

* Internal/AggressiveKeepLastWhc: changing the setting from the default
  made no sense whatsoever in Cyclone -- it would only add flow-control
  and potentially block a keep-last writer where the spec forbids that.

* Internal/LegacyFragmentation: a left-over from almost a decade ago when
  it was discovered that the specification was inconsistent in the use
  of the message header flags for fragmented data, and this stack for a
  while used the non-common interpretation.  There is no reasonable way of
  making the two modes compatible, and this setting merely existed to
  deal with the compatibility issue with some ancient OpenSplice DDS
  version.

* Durability/Encoding: historical junk.

* WatchDog and Lease: never had any function in Cyclone.

Signed-off-by: Erik Boasson <eb@ilities.com>
2019-05-23 18:51:23 +02:00
docs/dev Multi Process Testing framework 2019-05-23 18:51:23 +02:00
notes add some diagrams related to the data path 2018-07-04 15:59:55 +02:00
performance some minor improvements to the throughput test scripting 2019-01-22 09:15:18 +01:00
src remove legacy configuration settings 2019-05-23 18:51:23 +02:00
vdds-xcode/vdds-xcode.xcodeproj Initial contribution 2018-04-10 17:03:59 +02:00
.gitignore Fix build with openJDK-10 2018-06-23 21:51:21 +02:00
.gitmodules Initial contribution 2018-04-10 17:03:59 +02:00
.travis.yml Remove JAVA_HOME regarding registry from .travis.yml 2019-05-23 18:51:23 +02:00
appveyor.yml enable expensive checks in CI builds 2019-03-23 15:40:29 +01:00
conanfile.txt Require OpenSSL by default and add list it as a dependency for Conan 2019-02-01 10:39:49 +01:00
CONTRIBUTING.md Add README 2018-04-24 10:07:55 +02:00
LICENSE Initial contribution 2018-04-10 17:03:59 +02:00
NOTICE.md Add getopt 1.5 3rd party dependency 2018-05-08 10:18:52 +02:00
README.md Editing of README and next-steps following review comments 2019-02-16 08:54:17 +01:00

Eclipse Cyclone DDS

Eclipse Cyclone DDS is by far the most performant and robust DDS implementation available on the market. Moreover, Cyclone DDS is developed completely in the open as an Eclipse IoT project (see eclipse-cyclone-dds).

Getting Started

Building Eclipse Cyclone DDS

In order to build Cyclone DDS you need a Linux, Mac or Windows 10 machine with the following installed on your host:

  • CMake, version 3.7 or later. (Version 3.6 should work but you will have to edit the cmake_minimum_required version and may have to disable building the tests.)
  • OpenSSL, preferably version 1.1 or later. If you wish, you can build without support for OpenSSL by setting DDSC_ENABLE_OPENSSL to FALSE on the cmake command line (i.e., cmake -DDDSC_ENABLE_OPENSSL=FALSE ../src). In that, there is no need to have openssl available.
  • Java JDK, version 8 or later, e.g., OpenJDK 11.
  • Apache Maven, version 3.5 or later.

The Java-based components are the preprocessor and a configurator tool. The run-time libraries are pure C code, so there is no need to have Java available on "target" machines.

To obtain Eclipse Cyclone DDS, do

$ git clone https://github.com/eclipse-cyclonedds/cyclonedds.git 
$ cd cyclonedds
$ mkdir build

Depending on whether you want to develop applications using Cyclone DDS or contribute to it you can follow different procedures

For application developers

To build and install the required libraries needed to develop your own applications using Cyclone DDS requires a few simple steps. There are some small differences between Linux and macOS on the one hand, and Windows on the other. For Linux or macOS:

$ cd build
$ cmake -DCMAKE_INSTALL_PREFIX=<install-location> ../src
$ cmake --build .

and for Windows:

$ cd build
$ cmake -G "<generator-name>" -DCMAKE_INSTALL_PREFIX=<install-location> ../src
$ cmake --build .

where you should replace <install-location> by the directory under which you would like to install Cyclone DDS and <generator-name> by one of the ways CMake generators offer for generating build files. For example, "Visual Studio 15 2017 Win64" would target a 64-bit build using Visual Studio 2017.

To install it after a successful build, do:

$ cmake --build . --target install

which will copy everything to:

  • <install-location>/lib
  • <install-location>/bin
  • <install-location>/include/ddsc
  • <install-location>/share/CycloneDDS
  • <install-location>/etc/CycloneDDS

Depending on the installation location you may need administrator privileges.

At this point you are ready to use Eclipse Cyclone DDS in your own projects.

Note that the default build type is a release build with debug information included (RelWithDebInfo), which is generally the most convenient type of build to use from applications because of a good mix between performance and still being able to debug things. If you'd rather have a Debug or pure Release build, set CMAKE_BUILD_TYPE accordingly.

Contributing to Eclipse Cyclone DDS

We very much welcome all contributions to the project, whether that is questions, examples, bug fixes, enhancements or improvements to the documentation, or anything else really. When considering contributing code, it might be good to know that build configurations for Travis CI and AppVeyor are present in the repository and that there is a test suite using CTest and CUnit that can be built locally if desired. To build it, set the cmake variable BUILD_TESTING to on when configuring, e.g.:

$ cd build
$ cmake -DCMAKE_BUILD_TYPE=Debug -DBUILD_TESTING=ON ../src
$ cmake --build .
$ ctest

Such a build requires the presence of CUnit. You can install this yourself, or you can choose to instead rely on the Conan packaging system that the CI build infrastructure also uses. In that case, install Conan and do:

$ conan install ..

in the build directory prior to running cmake. For Windows, depending on the generator, you might also need to add switches to select the architecture and build type, e.g., conan install -s arch=x86_64 -s build_type=Debug .. This will automatically download and/or build CUnit (and, at the moment, OpenSSL).

Documentation

The documentation is still rather limited, and at the moment only available in the sources (in the form of restructured text files in src/docs and Doxygen comments in the header files), or as a PDF. The intent is to automate the process of building the documentation and have them available in more convenient formats and in the usual locations.

Performance

Median small message throughput measured using the Throughput example between two Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz (that's 2012 hardware ...) running Linux 3.8.13-rt14.20.el6rt.x86_64, connected via a quiet GbE and when using gcc-6.2.0 for a default (i.e., "RelWithDebInfo") build is:

Throughput

This is with the subscriber in polling mode. Listener mode is marginally slower; using a waitset the message rate for minimal size messages drops to 600k sample/s in synchronous delivery mode and about 750k samples/s in asynchronous delivery mode. The configuration is an out-of-the-box configuration, tweaked only to increase the high-water mark for the reliability window on the writer side. For details, see the scripts in the performance directory and the data.

There is some data on roundtrip latency below.

Building and Running the Roundtrip Example

We will show you how to build and run an example program that measures latency. The examples are built automatically when you build Cyclone DDS, so you don't need to follow these steps to be able to run the program, it is merely to illustrate the process.

$ cd cyclonedds/src/examples/roundtrip
$ mkdir build
$ cd build
$ cmake ..
$ make

On one terminal start the application that will be responding to pings:

$ ./RoundtripPong

On another terminal, start the application that will be sending the pings:

$ ./RoundtripPing 0 0 0 
# payloadSize: 0 | numSamples: 0 | timeOut: 0
# Waiting for startup jitter to stabilise
# Warm up complete.
# Round trip measurements (in us)
#             Round trip time [us]                           Write-access time [us]       Read-access time [us]
# Seconds     Count   median      min      99%      max      Count   median      min      Count   median      min
    1     28065       17       16       23       87      28065        8        6      28065        1        0
    2     28115       17       16       23       46      28115        8        6      28115        1        0
    3     28381       17       16       22       46      28381        8        6      28381        1        0
    4     27928       17       16       24      127      27928        8        6      27928        1        0
    5     28427       17       16       20       47      28427        8        6      28427        1        0
    6     27685       17       16       26       51      27685        8        6      27685        1        0
    7     28391       17       16       23       47      28391        8        6      28391        1        0
    8     27938       17       16       24       63      27938        8        6      27938        1        0
    9     28242       17       16       24      132      28242        8        6      28242        1        0
   10     28075       17       16       23       46      28075        8        6      28075        1        0

The numbers above were measured on Mac running a 4.2 GHz Intel Core i7 on December 12th 2018. From these numbers you can see how the roundtrip is very stable and the minimal latency is now down to 17 micro-seconds (used to be 25 micro-seconds) on this HW.

Trademarks

  • "Eclipse Cyclone DDS" and "Cyclone DDS" are trademarks of the Eclipse Foundation.

  • "DDS" is a trademark of the Object Management Group, Inc.