Recommended Targets

The cards are sorted by total score for this run. Each card is one tested URL or transport configuration; open it to see the URL, run mode, best and weakest latency cases, throughput, CPU, and counted cases.

Total score is out of 120. Higher is better for the current test mix. Sub-pills show: latency / throughput / resource / coverage / delivery / send-block. The "Recommended Targets" headline shows the strongest URL for this run.

Total score formula (max 120)
  • Latency 30% — Subscriber-side end-to-end latency. Per case we weight P95×0.70 + P99×0.25 + P99.9×0.04 + P99.99×0.01 through a payload-aware curve, then use an equal-weight geometric mean across cases.
  • Throughput 20% — recv MB/s on the subscriber side, log-scaled vs 1024 MB/s reference. Higher throughput → higher score.
  • Resource 10% — throughput per unit CPU. Lower CPU at the same throughput → higher score.
  • Delivery 10% — Aggregated loss across all cases: avg_delivery = 100 - loss%. Loss > 5% also lightly cuts per-case latency via a logistic curve (gentle ≤20%, accelerates >20%, capped at ×0.40) to defeat survivor-bias.
  • Send-block 10% — wall-clock time spent inside publish() per message (P99), equal-weight across latency/backpressure cases. Penalizes APIs that block the publisher thread.
  • Coverage 10% — Passing cases / total cases for this URL. Standalone dimension; also serves as fallback for the topology slot when topology suite is absent.
  • Topology 10% — Topology suite roll-up (1:n / n:1 / n:n). Falls back to clamp(coverage, 60, 95) when topology suite was not run.

total = (0.36·latency + 0.24·throughput + 0.12·resource + 0.12·delivery + 0.12·send-block + 0.12·coverage + 0.12·topology) · confidence_factor

Confidence is derived from aggregate/worst-case loss% and latency sample drops: <5% high, <15% medium, ≥15% noisy; solo means no peers, unknown means all cases failed. Multipliers: high 1.00 / solo·medium 0.99 / unknown·noisy 0.95.

Top recommendation: shm:// total 117/120
It is the strongest result in this run; use latency, throughput, and Transport Health below to confirm details.

#1shm://cross-process⚡ Latency score 98📦 Throughput score 100🔋 Resource score 100🎯 Coverage score 100📦 Delivery score 100🔒 Send-block score 85total 117conf high
protocol/transportshm://
URLshm://bench/perf_shm?depth=10
run modecross-process
best P95 latency21.4 us@ 128 B / 1000 Hz
weakest latency case93/100@ 128 B / 1000 Hz, P95 21.4 us, P99.9 338.8 us
peak received throughput11210.9 MB/s@ 256 KB
avg CPU117.2%publisher + subscriber
best send-block P995.26 us@ 16 KB
loss rate0.133%across all cases
counted runs8
#2dds://cross-process⚡ Latency score 78📦 Throughput score 86🔋 Resource score 33🎯 Coverage score 100📦 Delivery score 71🔒 Send-block score 32total 84conf noisy⚠ Loss 33.202%
protocol/transportdds://
URLdds://bench/perf_dds?qos=better
run modecross-process
best P95 latency47.2 us@ 128 B / 1000 Hz
weakest latency case51/100@ 2 MB / 1000 Hz, P95 2294.3 us, P99.9 2357.8 us
peak received throughput1349.0 MB/s@ 1 MB
avg CPU139.7%publisher + subscriber
best send-block P9925.60 us@ 128 B
loss rate33.202%across all cases
counted runs8
#3ddsc://cross-process⚡ Latency score 52📦 Throughput score 76🔋 Resource score 25🎯 Coverage score 100📦 Delivery score 95🔒 Send-block score 34total 75conf noisy⚠ Loss 75.855%
protocol/transportddsc://
URLddsc://bench/perf_ddsc?qos=better
run modecross-process
best P95 latency35.7 us@ 128 B / 1000 Hz
weakest latency case7/100@ 2 MB / 1000 Hz, P95 4755.3 us, P99.9 5212.3 us
peak received throughput1352.4 MB/s@ 256 KB
avg CPU157.2%publisher + subscriber
best send-block P9924.29 us@ 128 B
loss rate75.855%across all cases
counted runs8

Run Overview

Samples
24
Planned Cases
24
Skipped Cases
0
Cases
24
Passing
20
Warning
4
Failing
0

Repeated runs of the same case are merged; averages only count successful runs. Delivery loss is shown once it reaches 5% so trace amounts of normal jitter do not distract from the main result.

Metric Guide

Terminology used throughout the report. Skim it once and the recommendation, heatmaps, and category results below all become easier to interpret.

MetricMeaning
P50 / P90 / P99 latency (and P99.9 / P99.99 in detail tables)Latency percentiles. The heatmap shows P50 (typical), P90 (slower common case), and P99 (tail) side by side; detail tables also include P99.9 and P99.99 to surface rare slow messages. Lower numbers are better across the board.
Received MB/sHow many megabytes per second the subscriber actually received. This is the main throughput number.
Loss ratioMessages that were expected but not received. Small loss can happen in stress tests; the report only highlights loss at 5% or higher, and marks very high loss more strongly.
ConfidenceA quick read on result reliability, based on run success, visible loss, and latency sample drops. Low confidence means review Transport Health and problem cases; final judgment still depends on latency and throughput.
Message size / payloadThe size and type of each message sent during the test. Larger messages usually stress bandwidth, buffers, and copying more.
Connection topologyThe publisher/subscriber shape, such as 1:1, 1:n, n:1, or n:n. It shows whether a transport scales when more senders or receivers are involved.
CPU EfficiencyHow much throughput is achieved for the CPU used by publisher and subscriber. It helps break ties, but latency and throughput remain the main decision signals.

Transport Health

warnings

Transport Health tells whether this report is trustworthy before you compare scores. It summarizes failed cases, warnings, URL coverage, and problem cases. Green means no obvious problem; yellow means review loss, skipped, or unstable results; red means inspect the problem-case error first. Small loss is still recorded; this section highlights loss, failures, or skips that may affect the conclusion.

TransportModeProblem CasesTotal Cases
shmprocess08
ddsprocess18
ddscprocess38

Tested URL Coverage

TransportURLModesPassingWarningFailingBest Recv MB/sBest P95 us
shmshm://bench/perf_shm?depth=10process80011210.8821.45
ddsdds://bench/perf_dds?qos=betterprocess7101349.0047.15
ddscddsc://bench/perf_ddsc?qos=betterprocess530800.3835.67

Cases to Review

CategoryModeTransportPayloadConfigRepeatsStatusErrors
throughputprocessddsbytes / 16 KB
url: dds://bench/perf_dds?qos=better
topology: 1:1 [1p/1s]
pattern: max
1/1WARN 1/1 loss
throughputprocessddscbytes / 256 KB
url: ddsc://bench/perf_ddsc?qos=better
topology: 1:1 [1p/1s]
pattern: max
1/1WARN 1/1 loss
throughputprocessddscbytes / 1 MB
url: ddsc://bench/perf_ddsc?qos=better
topology: 1:1 [1p/1s]
pattern: max
1/1WARN 1/1 loss
latencyprocessddscbytes / 2 MB
url: ddsc://bench/perf_ddsc?qos=better
topology: 1:1 [1p/1s]
pattern: fixed
1/1WARN 1/1 loss

Latency / Throughput

Latency by Message Size (P50 / P90 / P99, lower is better)

Each cell has three bars: P50 / P90 / P99 (left to right), shorter and greener is better. Numbers on the right follow the same order, in µs. Blank = no data, FAIL = case failed.

low latencymedium latencyhigh latency
test target \ message size
128 B
4 KB
64 KB
512 KB
2 MB
shm://process | shm://bench/perf_shm?depth=10
P5015.0us
P9021.0us
P9924.8us
100/100
P5020.7us
P9021.8us
P9930.2us
100/100
P5038.0us
P9040.3us
P9949.0us
100/100
P5069.8us
P9073.0us
P99144us
100/100
P50484us
P90507us
P99536us
100/100
dds://process | dds://bench/perf_dds?qos=better
P5029.1us
P9046.0us
P9949.7us
100/100
P5048.2us
P9049.5us
P9998.2us
91/100
P5081.7us
P9086.4us
P99113us
97/100
P50383us
P90443us
P99469us
76/100
P501934us
P902273us
P992325us
54/100
ddsc://process | ddsc://bench/perf_ddsc?qos=better
P5028.9us
P9034.8us
P9939.0us
100/100
P5035.2us
P9038.9us
P9943.9us
100/100
P5092.3us
P90103us
P99113us
97/100
P50496us
P90645us
P99695us
57/100
P501935us
P904725us
P994869us
19/100

Throughput by Message Size (received MB/s, higher is better)

This chart uses throughput tests only. Each row is one test target and each column is a message size. The number is mean received MB/s. Longer greener horizontal bars mean the subscriber actually received more data. Blank or failed cells have no valid result.

test target \ message size
16 KB
256 KB
1 MB
shm://process | shm://bench/perf_shm?depth=10
5520 MB/s100/100
11211 MB/s100/100
9840 MB/s100/100
dds://process | dds://bench/perf_dds?qos=better
805 MB/s48/100
1114 MB/s50/100
1349 MB/s69/100
ddsc://process | ddsc://bench/perf_ddsc?qos=better
800 MB/s48/100
1352 MB/s54/100
413 MB/s43/100

Category Results

This table lists the best configuration in each test category. Different categories focus on different signals, so compare scores inside the same category.
ModeCategoryBest ResultScoreCoverageConclusion
processlatencyshm://
process | shm://bench/perf_shm?depth=10
98.55/5 case(s), 100.0% repeat success, 1 url(s)Lowest latency: P95 134.96 us, P99 156.95 us, P99.9 337.21 us, P99.99 835.94 us.
processthroughputshm://
process | shm://bench/perf_shm?depth=10
100.03/3 case(s), 100.0% repeat success, 1 url(s)Best throughput: received 8856.82 MB/s, first message 0.66 ms.
This table scores throughput, latency, backpressure, topology, and serialization separately. Compare scores inside the same category; a latency score and a throughput score are not interchangeable.
Each score is mainly driven by the most important metric for that category, with a small health check for failures, visible loss, latency sample drops, and repeat success.
CategoryWhat is scoredHow to read itBest used for
throughputMainly received MB/s, with small checks for send/receive efficiency and health.Throughput tests mainly answer how much data was actually received. Health only highlights clear problems.Useful for choosing the configuration that carries more data under larger payloads or heavier send pressure.
latencyMainly P95/P99 latency quality, with light tail-stability checks for P99.9/P99.99, max latency, jitter, throughput, and health.Latency tests mainly use percentiles. The heatmap visualises P50 (typical) / P90 (slower common case) / P99 (tail). P99.9 / P99.99 stay visible as tail-stability signals, but they do not dominate the score. Lower numbers are better.Useful for checking whether messages respond quickly and whether slow-message latency stays controlled. P95/P99 drive the score, while P99.9/P99.99 help explain rare stalls.
backpressureMainly publisher-side P99 send-block time, with checks for delivered throughput, send/receive efficiency, and health.Backpressure tests simulate slow consumers. Lower publish() blocking time is better, but the run still needs to deliver messages reliably.Useful for spotting transports that stall publisher threads when subscribers fall behind.
topologyMainly total received MB/s and scaling efficiency, with small checks for send/receive efficiency and health.Topology tests mainly check whether total throughput keeps up as publishers or subscribers increase.Useful for one-to-many, many-to-one, and many-to-many deployment shapes.
serializationMainly encode/decode speed, also checking coverage, repeat success, efficiency, balance, CPU, and memory.Serialization mainly compares encode/decode speed and checks repeat stability.Useful for judging data-format cost. It does not represent the full communication path.

Result Highlights

This run covers 3 url(s), 3 transport(s), and 1 mode(s). normal cases: 20/24; problem cases: 4.
The most normal cases come from shm in process mode with 8 normal case(s).
This section highlights the easiest results to notice in this report: highest throughput, lowest latency, topology scaling, and fastest encode/decode. Use it to find leads quickly, then confirm with the recommendation, heatmaps, and problem cases.
Highest 1:1 throughput: shm | process | 1:1 [1p/1s] | bytes | 256 KB
received 11210.88 MB/s | first msg 0.48 ms | repeats 1/1
url: shm://bench/perf_shm?depth=10
Lowest 1:1 latency: shm | process | 1:1 [1p/1s] | bytes | 128 B
p95 21.45 us | p99 24.82 us | received 0.12 MB/s | repeats 1/1
url: shm://bench/perf_shm?depth=10

Transport Summary

Groups each URL/transport configuration into one row for a quick trend view. A row can include multiple message sizes, rates, or topologies, so use latency/throughput comparisons and trend charts for exact comparisons.

Groups results by transport type, run mode, and test category for a quick trend view. Because a row can include multiple message sizes or rates, use latency/throughput comparisons and trend charts for exact comparisons.
TransportModeURLCategoryScoreCoverageMean Received MB/sMean Run P95 usLoss %Mean Peak RSS MB
shmprocessshm://bench/perf_shm?depth=10latency98.55/5 | 100.0% repeat513.31134.96-39.0
ddsprocessdds://bench/perf_dds?qos=betterlatency79.25/5 | 100.0% repeat314.31588.51-42.7
ddscprocessddsc://bench/perf_ddsc?qos=betterlatency66.75/5 | 100.0% repeat237.511122.1061.92542.0
shmprocessshm://bench/perf_shm?depth=10throughput100.03/3 | 100.0% repeat8856.82--43.0
ddsprocessdds://bench/perf_dds?qos=betterthroughput89.23/3 | 100.0% repeat1089.32-33.20243.0
ddscprocessddsc://bench/perf_ddsc?qos=betterthroughput82.73/3 | 100.0% repeat855.25-75.85542.1

Trend Charts

Throughput (process)

Throughput: Received MB/s vs Payload Size1121189696727448422420.0016 KB256 KB1 MBPayload SizeReceived MB/s

Latency (process)

Latency: Mean Run P95 us vs Payload Size10000100010010.0128 B4 KB64 KB512 KB2 MBPayload SizeMean Run P95 Latency (us)

Loss (process)

Loss: Loss Ratio vs Payload Size10010.01.000.100.01128 B4 KB64 KB512 KB2 MBPayload SizeLoss (%)

Send-block (process)

Send-block: P99 publish() blocking vs Payload Size10000100010010.0128 B4 KB64 KB512 KB2 MBPayload SizeSend-block P99 (us)

First Message (process)

First Message ms vs Payload Size4.413.532.651.770.880.0016 KB256 KB1 MBPayload SizeFirst Message (ms)

Resource CPU (process)

Resource: CPU% vs Payload Size22317813489.044.50.0016 KB256 KB1 MBPayload SizeCPU (%)

Resource RSS (process)

Resource: Peak RSS MB vs Payload Size47.538.028.519.09.490.0016 KB256 KB1 MBPayload SizePeak RSS MB

Detail Tables

Transport Detail Table

CategoryModeTransportPayloadConfigRateRepeatsReceived MB/sMean P95 usMean P99.9 usSend-block P99 usLoss %CPU %Peak RSS MBStatus
throughputprocessshmbytes / 16 KB
url: shm://bench/perf_shm?depth=10
topology: 1:1 [1p/1s]
pattern: max
max1/15519.59--5.260.00191.9244.0OK 1/1
throughputprocessshmbytes / 256 KB
url: shm://bench/perf_shm?depth=10
topology: 1:1 [1p/1s]
pattern: max
max1/111210.88--24.200.13129.5542.4OK 1/1
throughputprocessshmbytes / 1 MB
url: shm://bench/perf_shm?depth=10
topology: 1:1 [1p/1s]
pattern: max
max1/19840.00--80.330.00108.8342.6OK 1/1
throughputprocessddsbytes / 16 KB
url: dds://bench/perf_dds?qos=better
topology: 1:1 [1p/1s]
pattern: max
max1/1805.22--26.9133.20222.5041.8WARN 1/1 loss
throughputprocessddsbytes / 256 KB
url: dds://bench/perf_dds?qos=better
topology: 1:1 [1p/1s]
pattern: max
max1/11113.75--263.500.02153.9241.9OK 1/1
throughputprocessddsbytes / 1 MB
url: dds://bench/perf_dds?qos=better
topology: 1:1 [1p/1s]
pattern: max
max1/11349.00--822.720.18160.2945.4OK 1/1
throughputprocessddscbytes / 16 KB
url: ddsc://bench/perf_ddsc?qos=better
topology: 1:1 [1p/1s]
pattern: max
max1/1800.38--40.520.00212.3039.0OK 1/1
throughputprocessddscbytes / 256 KB
url: ddsc://bench/perf_ddsc?qos=better
topology: 1:1 [1p/1s]
pattern: max
max1/11352.38--170.1322.79209.0639.7WARN 1/1 loss
throughputprocessddscbytes / 1 MB
url: ddsc://bench/perf_ddsc?qos=better
topology: 1:1 [1p/1s]
pattern: max
max1/1413.00--639.4475.86199.4147.5WARN 1/1 loss
latencyprocessshmbytes / 128 B
url: shm://bench/perf_shm?depth=10
topology: 1:1 [1p/1s]
pattern: fixed
1000Hz1/10.1221.45338.7610.660.00101.2837.4OK 1/1
latencyprocessshmbytes / 4 KB
url: shm://bench/perf_shm?depth=10
topology: 1:1 [1p/1s]
pattern: fixed
1000Hz1/13.9123.1249.2512.230.00101.4937.4OK 1/1
latencyprocessshmbytes / 64 KB
url: shm://bench/perf_shm?depth=10
topology: 1:1 [1p/1s]
pattern: fixed
1000Hz1/162.5041.4361.9411.000.00101.1837.5OK 1/1
latencyprocessshmbytes / 512 KB
url: shm://bench/perf_shm?depth=10
topology: 1:1 [1p/1s]
pattern: fixed
1000Hz1/1500.0074.34329.8046.760.00101.6939.3OK 1/1
latencyprocessshmbytes / 2 MB
url: shm://bench/perf_shm?depth=10
topology: 1:1 [1p/1s]
pattern: fixed
1000Hz1/12000.00514.47906.29138.190.00101.2843.2OK 1/1
latencyprocessddsbytes / 128 B
url: dds://bench/perf_dds?qos=better
topology: 1:1 [1p/1s]
pattern: fixed
1000Hz1/10.1247.1561.4825.600.00103.9740.5OK 1/1
latencyprocessddsbytes / 4 KB
url: dds://bench/perf_dds?qos=better
topology: 1:1 [1p/1s]
pattern: fixed
1000Hz1/13.9151.24260.8153.420.00104.3440.6OK 1/1
latencyprocessddsbytes / 64 KB
url: dds://bench/perf_dds?qos=better
topology: 1:1 [1p/1s]
pattern: fixed
1000Hz1/162.5089.74323.3951.730.00105.3040.8OK 1/1
latencyprocessddsbytes / 512 KB
url: dds://bench/perf_dds?qos=better
topology: 1:1 [1p/1s]
pattern: fixed
1000Hz1/1500.00460.08598.91436.700.00124.7043.0OK 1/1
latencyprocessddsbytes / 2 MB
url: dds://bench/perf_dds?qos=better
topology: 1:1 [1p/1s]
pattern: fixed
1000Hz1/11005.002294.322357.831655.210.10142.7348.5OK 1/1
latencyprocessddscbytes / 128 B
url: ddsc://bench/perf_ddsc?qos=better
topology: 1:1 [1p/1s]
pattern: fixed
1000Hz1/10.1235.6746.2524.290.00103.1836.2OK 1/1
latencyprocessddscbytes / 4 KB
url: ddsc://bench/perf_ddsc?qos=better
topology: 1:1 [1p/1s]
pattern: fixed
1000Hz1/13.9139.4350.2526.080.00103.2236.3OK 1/1
latencyprocessddscbytes / 64 KB
url: ddsc://bench/perf_ddsc?qos=better
topology: 1:1 [1p/1s]
pattern: fixed
1000Hz1/162.50106.83132.4674.480.00105.7539.3OK 1/1
latencyprocessddscbytes / 512 KB
url: ddsc://bench/perf_ddsc?qos=better
topology: 1:1 [1p/1s]
pattern: fixed
1000Hz1/1500.00673.28890.24514.410.00139.2742.5OK 1/1
latencyprocessddscbytes / 2 MB
url: ddsc://bench/perf_ddsc?qos=better
topology: 1:1 [1p/1s]
pattern: fixed
1000Hz1/1621.004755.275212.261276.7761.93185.3455.7WARN 1/1 loss