Comparable DDS Measurements

Complete DDS measurement boundary

The complete DDS charts time every application stage from write() to take(). Discovery and matching happen before the timer starts.

Current Tin DDS and Retina build

This current-source cohort exchanged the same 64-byte application sample between two CPU-pinned processes over reliable UDP. Each implementation completed five interleaved runs of 10,000 measured round trips after 500 warm-up exchanges. The timer covers the complete public write()-to-take() path, and all 100,000 measured exchanges arrived without loss, duplication, or rejection.

The median statistics come from one ARM64 host session. Its scheduler and power state can move absolute latency, so this cohort remains separate from the earlier five-implementation comparison. The machine-readable matrix links to all ten raw observation artifacts and their source and compiler metadata.

Five DDS implementations, one workload

Tin DDS, Retina, CycloneDDS, Fast DDS, and RTI Connext each exchange the same 64-byte application sample between two processes over reliable UDP. Discovery and 500 warm-up exchanges finish before 10,000 observations are retained. The charts report the median statistic from five interleaved, CPU-pinned runs on one ARM64 Linux host. Batching is off and durability is volatile for every implementation. Each row is a homogeneous pair of that implementation; this chart measures performance, not mixed-vendor interoperability.

Every run retained exactly 10,000 observations and completed without a reported lost exchange. The machine-readable matrix links to all 25 run artifacts and their raw latency observations.

Reliable DDS latency as payload size grows

Tin DDS and Retina completed 90,000 reliable round trips through their public writer and reader APIs with zero lost samples. Each run establishes discovery and endpoint matching before 500 warm-up exchanges, then measures serialization, reliability, history, UDP transport, and application delivery. The table reports the median of three interleaved runs on a provenance-complete, slim Tinverse Linux Guix GCP runner image.

These runs used the Tinverse Linux v4-lto policy on a c3-standard-4 VM, with publishers pinned to CPU 1 and subscribers to CPU 3.

Complete DDS publish-to-receive latency

These Retina results measure from the application calling write() until the receiving application obtains the sample with take(). Each direction includes CDR serialization, writer history and reliability, RTPS DATA framing, shared memory or UDP, RTPS parsing, reader reliability and history, and CDR deserialization. SPDP/SEDP discovery, endpoint matching, and warm-up finish before timing begins.

Each row is the median of five interleaved one-million-sample runs. The latency is a one-way estimate obtained by dividing a complete ping-pong round trip by two. Every run delivered every sample without loss or retransmission. The machine-readable result records the measurement boundary, aggregation, and delivery counters.

Reliable when delivery is disrupted

Tin DDS and Retina each recovered every one of 15,000 trials for four RTPS reliability behaviors: rejecting duplicate data, accepting data that arrives out of order, requesting a missing sequence, and requesting a missing fragment. Across both implementations, all 120,000 trials completed successfully.

These deterministic checks isolate the reliability mechanisms from the network. Their internal timings cover different amounts of work, so the result reported here is recovery correctness, not a speed ranking. The summary and complete trial records are available for inspection.

Reliable and best-effort local fanout

One write was delivered to 1, 4, or 16 readers through each implementation's DDS history and matching logic. Tin DDS and Retina completed 180,000 measured write-and-take iterations with no lost, duplicate, or rejected deliveries. The Release runs alternate implementation order and retain every latency sample.

Latency is one complete logical iteration: one write followed by a take from every reader. Delivery rate counts reader deliveries, so it rises with fanout. This is local DDS dispatch, not UDP latency. See the summary and raw child artifacts.

Performance with the DDS behavior included

The reliable UDP results exercise public typed writers and readers in separate processes. Discovery, endpoint matching, serialization, reliability, history, transport, and application delivery are part of the path. A run passes only when its delivery accounting is complete; latency alone is not enough.

Split-process cohort (July–August 2026)

Every row uses a publisher and subscriber in separate persistent processes on one host. Measurements were collected on an ARM64 system and an x86-64 system. The linked artifacts record the workload and measurement method; duration-based vendor tools may complete a different number of round trips than the fixed-iteration tin-dds and Retina runners.

The rows share a process topology and payload size. Mechanism tables time loan and notification work; full DDS tables include their implementation's wider DDS path. Those scopes are deliberately separated and are not ranked against each other. Treat these as same-host reference points, not universal rankings: CPU scheduling, power mode, configuration, and payload size all affect the result.

The ARM64 UDP rows were refreshed together on August 18, 2026 using the matched five-implementation workload above. The x86-64 reference rows and ARM64 shared-memory mechanism rows come from their separately linked cohorts and are not mixed into that ranking.

Additional numeric datasets