-
Notifications
You must be signed in to change notification settings - Fork 23
/
perftest_qos_profiles.xml
1103 lines (935 loc) · 45.2 KB
/
perftest_qos_profiles.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="iso-8859-1"?>
<!--
(c) 2005-2017 Copyright, Real-Time Innovations, Inc. All rights reserved.
Subject to Eclipse Public License v1.0; see LICENSE.md for details.
-->
<!--
This file contains the QoS configurations used by the RTI PerfTest, a
performance test for measuring the latency of the middleware at different
throughput levels.
The format of this file is described in the RTI Connext Core Libraries
and Utilities User's Manual in the chapter titled "Configuring QoS with XML."
-->
<!--
Equivalence between variable names and command-line options within the source code:
_DataLen variable name corresponds to the command-line option -dataLen
_SendQueueSize variable name corresponds to the command-line option -sendQueueSize
_InstanceCount variable name corresponds to the command-line option -instances
_InstanceHashBuckets variable name corresponds to the command-line option -instanceHashBuckets
_KeepDurationUsec variable name corresponds to the command-line option -keepDurationUsec
-->
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="https://community.rti.com/schema/7.2.0/rti_dds_profiles.xsd">
<qos_library name="PerftestQosLibrary">
<!-- ================================================================= -->
<!-- Base QoS Profile -->
<!-- ================================================================= -->
<!--
This profile is used as the base for all the profiles defined in this XML file.
-->
<qos_profile name="BaseProfileQos">
<participant_qos>
<!-- === Participant Configuration: ================================
The base configuration of the DomainParticipant object.
This element corresponds to the DomainParticipantQos type, which is described
in detail in the API Reference HTML documentation. Each child element corresponds
to a field in that structure with the same name. Any parameter not listed
here will pick up the documented default value.
-->
<receiver_pool>
<!--
The receive buffer is used by the receive thread to store the raw data
that arrives over the transport.
The ReceiverPoolQosPolicy's buffer_size should be set to be the same value
as the maximum ::NDDS_Transport_Property_t::message_size_max across all of
the transports being used. This value is automatically picked based on that
parameter. So we will not set it here.
-->
<!-- <buffer_size>65536</buffer_size> -->
</receiver_pool>
<resource_limits>
<!--
Maximum size of a serialized type code.
This parameter limits the size of the type code that a DomainParticipant
is able to store and propagate for data types.
-->
<type_code_max_serialized_length>2048</type_code_max_serialized_length>
<!--
Maximum string length of the properties associated with the DomainParticipant.
The string length is defined as the cumulative length, in bytes, including the
null terminating characters, of all the (name,value) pairs associated with the
DomainParticipant properties.
-->
<participant_property_string_max_length>4096</participant_property_string_max_length>
<!--
Maximum number of properties associated with the DomainParticipant. Default is 32.
-->
<participant_property_list_max_length>64</participant_property_list_max_length>
<!--
Maximum length for content filter property in the DomainParticipant. Default is 256.
-->
<contentfilter_property_max_length>512</contentfilter_property_max_length>
</resource_limits>
<!--
Specifies which built-in transports are used.
Three different transport plug-ins are built into the Connext core
libraries (for most supported target platforms): UDPv4, shared memory, and
UDPv6.
By default RTI Perftest uses UDPv4|SHMEM, default values for RTI
Connext DDS. By using the command-line option -transport we enabled
the use of:
- UDPv4
- UDPv6
- SHMEM
- TCP
- TLS
- DTLS
- WAN
For custom transport settings, modify this profile.
-->
<!--
<transport_builtin>
<mask>UDPv4|SHMEM</mask>
</transport_builtin>
-->
<property>
<value>
<!--
Starting after Connext DDS Pro 6.0.0, properties will be validated
to avoid mistakes or wrong configurations, however we set certain
properties for TCP, and later we decide if we want to use TCP or
not, and that would conflict with the Pro feature, so we disable it.
-->
<element>
<name>dds.participant.property_validation_action</name>
<value>1</value>
</element>
<!--
Specifies the configuration to be used with the UDPv4 built-in transport.
-->
<element>
<name>dds.transport.UDPv4.builtin.parent.message_size_max</name>
<value>65536</value>
</element>
<element>
<name>dds.transport.UDPv4.builtin.send_socket_buffer_size</name>
<value>1048576</value>
</element>
<element>
<name>dds.transport.UDPv4.builtin.recv_socket_buffer_size</name>
<value>2097152</value>
</element>
<!--
Specifies the configuration to be used with the SHMEM built-in transport.
Important: The following settings are configured automatically within the
source code. If you wish to set them yourself, uncomment the settings
<element>
<name>dds.transport.shmem.builtin.parent.message_size_max</name>
<value>65536</value>
</element>
<element>
<name>dds.transport.shmem.builtin.received_message_count_max</name>
<value>128</value>
</element>
<element>
<name>dds.transport.shmem.builtin.receive_buffer_size</name>
<value>2097152</value>
</element>
-->
<!--
Specifies the configuration to be used with the TCP transport.
If TCP is enabled using -transport TCP, the load_plugins property is set
within the source code.
Important: nddstransporttcp.dll is located in NDDSHOME/lib/<architecture>.
That folder must be added to the PATH on Windows systems and LD_LIBRARY_PATH
on linux systems in order to load this library properly. If you are
compiling PerfTest using CSHARP, you must also add the folder
NDDSHOME/lib/i86Win32VS<version> or NDDSHOME/lib/x64Win64VS<version> depending
on the machine.
<element>
<name>dds.transport.load_plugins</name>
<value>dds.transport.TCPv4.tcp1</value>
</element>
-->
<element>
<name>dds.transport.TCPv4.tcp1.library</name>
<value>nddstransporttcp</value>
</element>
<element>
<name>dds.transport.TCPv4.tcp1.create_function</name>
<value>NDDS_Transport_TCPv4_create</value>
</element>
<element>
<name>dds.transport.TCPv4.tcp1.disable_nagle</name>
<value>1</value>
</element>
<element>
<name>dds.transport.TCPv4.tcp1.parent.message_size_max</name>
<value>65536</value>
</element>
<!-- Defining flow controller 10Gbps. This will not enable it. -->
<element>
<name>dds.flow_controller.token_bucket.10Gbps.token_bucket.max_tokens</name>
<value>300</value>
</element>
<element>
<name>dds.flow_controller.token_bucket.10Gbps.token_bucket.tokens_added_per_period</name>
<value>200</value>
</element>
<element>
<name>dds.flow_controller.token_bucket.10Gbps.token_bucket.bytes_per_token</name>
<value>65536</value>
</element>
<element>
<name>dds.flow_controller.token_bucket.10Gbps.token_bucket.period.sec</name>
<value>0</value>
</element>
<element>
<name>dds.flow_controller.token_bucket.10Gbps.token_bucket.period.nanosec</name>
<value>10000000</value>
</element>
<!-- Defining flow controller 1Gbps. This will not enable it. -->
<element>
<name>dds.flow_controller.token_bucket.1Gbps.token_bucket.max_tokens</name>
<value>30</value>
</element>
<element>
<name>dds.flow_controller.token_bucket.1Gbps.token_bucket.tokens_added_per_period</name>
<value>20</value>
</element>
<element>
<name>dds.flow_controller.token_bucket.1Gbps.token_bucket.bytes_per_token</name>
<value>65536</value>
</element>
<element>
<name>dds.flow_controller.token_bucket.1Gbps.token_bucket.period.sec</name>
<value>0</value>
</element>
<element>
<name>dds.flow_controller.token_bucket.1Gbps.token_bucket.period.nanosec</name>
<value>10000000</value>
</element>
<!--
This QoS is applied when using security. Default starting in 7.0.0
is aes-256-gcm
-->
<element>
<name>com.rti.serv.secure.cryptography.encryption_algorithm</name>
<value>aes-128-gcm</value>
</element>
</value>
</property>
<!--
Specifies the participant name. This setting is useful when using monitoring
applications.
-->
<participant_name>
<name>PerfTest Participant</name>
</participant_name>
</participant_qos>
<!-- === Publisher Configuration: =================================
The base configuration of the Publisher object.
This element corresponds to the PublisherQos type, which is described
in detail in the API Reference HTML documentation. Each child element
corresponds to a field in that structure with the same name. Any
parameter not listed here will pick up the documented default value.
-->
<publisher_qos>
<presentation>
<!--
Access Scope: Determines the largest scope spanning the entities
for which the order and coherency of changes can be preserved.
Ordered Access: Specifies support for ordered access to the samples
received at the subscription end.
-->
<access_scope>TOPIC_PRESENTATION_QOS</access_scope>
<ordered_access>true</ordered_access>
</presentation>
</publisher_qos>
<!-- === Subscriber Configuration: =================================
The base configuration of the Subscriber object.
This element corresponds to the SubscriberQos type, which is described
in detail in the API Reference HTML documentation. Each child element
corresponds to a field in that structure with the same name. Any
parameter not listed here will pick up the documented default value.
-->
<subscriber_qos>
<presentation>
<!--
Access Scope: Determines the largest scope spanning the entities
for which the order and coherency of changes can be preserved.
Ordered Access: Specifies support for ordered access to the samples
received at the subscription end.
-->
<access_scope>TOPIC_PRESENTATION_QOS</access_scope>
<ordered_access>true</ordered_access>
</presentation>
</subscriber_qos>
<!-- === DataWriter Configuration: ==================================
The base configuration of the DataWriter object that produces throughput
data (the -pub side of the application).
This element corresponds to the DataWriterQos type, which is described
in detail in the API Reference HTML documentation. Each child element
corresponds to a field in that structure with the same name. Any
parameter not listed here will pick up the documented default value.
-->
<datawriter_qos>
<resource_limits>
<!--
The number of instances for which the throughput DataWriter will
allocate space. The throughput topic is not keyed, so there is no
need for more than one instance.
See Section 2.2 "Data Types, Topics, Keys, Instances, and Samples"
in the Connext Core Libraries and Utilities User's Manual
for more information about keys and instances.
Important: These settings are configured automatically within the
source code. The default value of _InstanceCount is 1. The default
value of _InstanceHashBuckets is -1.
<max_instances>_InstanceCount</max_instances>
<initial_instances>_InstanceCount</initial_instances>
if _InstanceCount is greater than 1
if _InstanceHashBuckets is greater than 0
<instance_hash_buckets>_InstanceHashBuckets</instance_hash_buckets>
if _InstanceHashBuckets is equal or lower than 0
<instance_hash_buckets>_InstanceCount</instance_hash_buckets>
-->
</resource_limits>
<protocol>
<rtps_reliable_writer>
<!--
When positive acknowledgements have been disabled, the DataWriter will
consider samples as positively "acknowledged" after this duration has
elapsed if it has not heard otherwise.
We disable the positive acknowledgements in perftest by using:
-disablePositiveAcks. You can alternatively enable them via QoS by
adding <disable_positive_acks>true</disable_positive_acks> in the
<protocol> QoS of the DW and DR of the ThroughputQoS and LatencyQoS.
The default value of _KeepDurationUsec can be configured here or via the
command line parameter -keepDuration.
-->
<disable_positive_acks_min_sample_keep_duration>
<sec>DURATION_ZERO_SEC</sec>
<nanosec>100000</nanosec>
</disable_positive_acks_min_sample_keep_duration>
</rtps_reliable_writer>
</protocol>
</datawriter_qos>
<!-- === DataReader Configuration: ================================= -->
<!--
The base configuration of the DataReader object that consumes throughput
data (the -sub side of the application).
This element corresponds to the DataReaderQos type, which is described
in detail in the API Reference HTML documentation. Each child element
corresponds to a field in that structure with the same name. Any
parameter not listed here will pick up the documented default value.
-->
<datareader_qos>
<resource_limits>
<!--
The initial and maximum number of instances for which the middleware
will allocate space. See the corresponding DataWriterQos comment above
for more information.
Important: This settings are configured automatically within the source code.
The default value of _InstanceCount is 1.
The default value of _InstanceMaxCountReader is -1.
The default value of _InstanceHashBuckets is -1.
<max_instances>_InstanceMaxCountReader</max_instances>
<initial_instances>_InstanceCount</initial_instances>
if _InstanceCount is greater than 1 and
if _InstanceHashBuckets is greater than 0
<instance_hash_buckets>_InstanceHashBuckets</instance_hash_buckets>
if _InstanceHashBuckets is equal or lower than 0
<instance_hash_buckets>_InstanceCount</instance_hash_buckets>
-->
</resource_limits>
</datareader_qos>
</qos_profile>
<!-- ================================================================= -->
<!-- Throughput QoS Profile -->
<!-- ================================================================= -->
<!--
This profile is used by the throughput-testing portion of the application,
provided that positive acknowledgements have not been disabled with the
'-noPositiveAcks' command-line argument or 'use positive acks = false'
in the .ini configuration file.
-->
<qos_profile name="ThroughputQos" base_name="BaseProfileQos">
<!-- === DataWriter Configuration: =================================
The base configuration of the DataWriter object that produces throughput
data (the -pub side of the application).
This element corresponds to the DataWriterQos type, which is described
in detail in the API Reference HTML documentation. Each child element
corresponds to a field in that structure with the same name. Any
parameter not listed here will pick up the documented default value.
-->
<datawriter_qos>
<writer_resource_limits>
<max_remote_reader_filters>256</max_remote_reader_filters>
</writer_resource_limits>
<!--
Setting history.kind = KEEP_ALL, Connext will attempt to maintain
and deliver all the values of the instance to existing subscribers.
The resources that Connext can use to keep this history are limited
by the settings of the RESOURCE_LIMITS.
-->
<history>
<kind>KEEP_ALL_HISTORY_QOS</kind>
</history>
<!--
Setting reliability.kind = RELIABLE_RELIABILITY_QOS, data samples
originating from a single DataWriter cannot be made available to the
DataReader if there are previous data samples that have not been
received yet due to a communication error.
The default value of reliability.kind is RELIABLE_RELIABILITY_QOS.
The reliability.kind can be modified to BEST_EFFORT_RELIABILITY_QOS
by using the command-line option -bestEffort.
-->
<reliability>
<kind>RELIABLE_RELIABILITY_QOS</kind>
<max_blocking_time>
<sec>DURATION_INFINITE_SEC</sec>
<nanosec>DURATION_INFINITE_NSEC</nanosec>
</max_blocking_time>
</reliability>
<resource_limits>
<!--
The number of data samples for which the DataWriter will allocate
space. The throughput test is configured without durability, meaning
that when all DataReaders have acknowledged a sample, the DataWriter
will discard it. The values below, then, effectively indicate how
far ahead of the slowest reader the writer is able to get before it
will block waiting for the reader(s) to catch up.
See the parallel DataReaderQos comment above for more information
about the relationships between these three values.
Important: These settings are configured automatically within the
source code.
_SendQueueSize = 50 (default)
_SendQueueSize can be configured using the command-line option -sendQueueSize <value>
if batching is not set:
<max_samples>_SendQueueSize</max_samples>
<initial_samples>_SendQueueSize</initial_samples>
<max_samples_per_instance>_SendQueueSize</max_samples_per_instance>
if batching is set:
<max_samples>DDS_LENGTH_UNLIMITED</max_samples>
<initial_samples>_SendQueueSize</initial_samples>
<max_samples_per_instance>DDS_LENGTH_UNLIMITED</max_samples_per_instance>
-->
</resource_limits>
<protocol>
<rtps_reliable_writer>
<!--
When the writer's cache gets down to this number of samples, it
will slow the rate at which it sends heartbeats to readers.
Important: This setting is configured automatically within the source code.
<low_watermark>_SendQueueSize * 0.1</low_watermark>
-->
<!--
When the writer's cache is filled to this level, it will begin
sending heartbeats at a faster rate in order to spur faster
acknowledgements (positive or negative) of its samples to allow it
to empty its cache and avoid blocking.
Important: This setting is configured automatically within the source code.
<high_watermark>_SendQueueSize * 0.9</high_watermark>
-->
<!--
Governs how often heartbeats are "piggybacked" on data samples.
Important: This setting is configured automatically within the source code.
<heartbeats_per_max_samples>_SendQueueSize * 0.1</heartbeats_per_max_samples>
-->
<!--
Minimum and maximum size of send window of unacknowledged samples.
Important: These settings are configured automatically within the source code.
<min_send_window_size>datawriter_qos.resource_limits.max_samples</min_send_window_size>
<max_send_window_size>datawriter_qos.resource_limits.max_samples</max_send_window_size>
-->
<!--
If the number of samples in the writer's cache hasn't risen to
high_watermark, this is the rate at which the DataWriter will
send out periodic heartbeats.
-->
<heartbeat_period>
<sec>DURATION_ZERO_SEC</sec>
<nanosec>10000000</nanosec>
</heartbeat_period>
<!--
If the number of samples in the writer's cache has risen to
high_watermark, and has not yet fallen to low_watermark, this is
the rate at which the writer will send periodic heartbeats to
its readers.
-->
<fast_heartbeat_period>
<sec>DURATION_ZERO_SEC</sec>
<nanosec>1000000</nanosec>
</fast_heartbeat_period>
<!--
If a durable reader starts up after the writer already has some
samples in its cache, this is the rate at which it will heartbeat
the new reader. It should generally be a shorter period of time
than the normal heartbeat period in order to help the new reader
catch up.
-->
<late_joiner_heartbeat_period>
<sec>DURATION_ZERO_SEC</sec>
<nanosec>10000000</nanosec>
</late_joiner_heartbeat_period>
<!--
The number of times a reliable writer will send a heartbeat to
a reader without receiving a response before it will consider the
reader to be inactive and no longer await acknowledgements before
discarding sent data.
-->
<max_heartbeat_retries>LENGTH_UNLIMITED</max_heartbeat_retries>
<!--
When a DataWriter receives a negative acknowledgement (NACK) from
a DataReader for a particular data sample, it will send a repair
packet to that reader.
The amount of time the writer waits between receiving the NACK and
sending the repair will be a random value between the minimum
and maximum values specified here. Narrowing the range, and
shifting it towards zero, will make the writer more reactive.
However, by leaving some delay you increase the chance that the
writer will learn of additional readers that missed the same data,
in which case it will be able to send a single multicast repair
instead of multiple unicast repairs, thereby using the available
network bandwidth more efficiently. The higher the fanout in your
system (i.e., the more readers per writer), and the greater the
load on your network, the more you should consider specifying a
non-zero delay here.
-->
<min_nack_response_delay>
<sec>DURATION_ZERO_SEC</sec>
<nanosec>DURATION_ZERO_NSEC</nanosec>
</min_nack_response_delay>
<max_nack_response_delay>
<sec>DURATION_ZERO_SEC</sec>
<nanosec>DURATION_ZERO_NSEC</nanosec>
</max_nack_response_delay>
</rtps_reliable_writer>
</protocol>
<!--
When sending many small data-samples, you can increated network efficiency
by batching multiple samples together in a single protocol-level message
(usually corresponding to a single network datagram). Batching can offer very
substantial throughput gains, but often at the expense of latency, although
in some configurations, the latency penalty can be very small or zero,
possibly even negative.
-->
<!--
Important: This setting is configured automatically within the source code,
but only if batching is enabled. _SendQueueSize = 50 (default)
<writer_resource_limits>
<max_batches>_SendQueueSize</max_batches>
</writer_resource_limits>
-->
<batch>
<!--
This profile does not enable batching, although the remaining
batching settings are configured as if it did. To enable the batch
configuration below, turn batching on using the app's command-line
or INI file.
-->
<enable>false</enable>
<!--
Batches can be "flushed" to the network based on a maximum size.
This size can be based on the total number of bytes in the
accumulated data samples, the total number of bytes in the
accumulated sample meta-data (e.g., timestamps, sequence numbers,
etc.), and/or the number of samples. Whenever the first of these
limits is reached, the batch will be flushed.
Important: This setting is configured automatically within the source code.
<max_data_bytes>_BatchSize</max_data_bytes>
-->
<max_meta_data_bytes>LENGTH_UNLIMITED</max_meta_data_bytes>
<max_samples>LENGTH_UNLIMITED</max_samples>
<!--
The middleware will associate a source timestamp with a batch when
it is started. The duration below indicates the amount of time that
may pass before the middleware will insert an additional timestamp
into the middle of an existing batch.
Shortening this duration can give readers increased timestamp
resolution. However, lengthening this duration
decreases the amount of meta-data on the network, potentially
improving throughput, especially if the data samples are very small.
If this delay is set to an infinite time period, timestamps will
be inserted only once per batch. Furthermore, the middleware will
not need to check the time with each sample in the batch, reducing
the amount of computation on the send path and potentially improving
both latency and throughput performance.
-->
<source_timestamp_resolution>
<sec>DURATION_INFINITE_SEC</sec>
<nanosec>DURATION_INFINITE_NSEC</nanosec>
</source_timestamp_resolution>
<!--
The maximum flush delay. A batch is flushed automatically after the
delay specified by this parameter. As its value is DURATION_INFINITE,
the flush event will be triggered by max_data_bytes.
-->
<max_flush_delay>
<sec>DURATION_INFINITE_SEC</sec>
<nanosec>DURATION_INFINITE_NSEC</nanosec>
</max_flush_delay>
<!--
By default, the same DataWriter can be used from multiple threads.
If you know that your application will only write data from a single
thread, you can switch off a level of locking that occurs when
samples are added to a batch. When sending very small samples very
fast, this decreased overhead can improve performance.
However, even in the case of single-threaded access, the impact of
locking can be negligible, and deactivating the lock puts your
application at risk of memory corruption if multiple threads do
write to the same DataWriter - either without your knowledge or as
a result of application maintenance. Therefore, RTI recommends that
you only set thread_safe_write to false after detailed testing has
confirmed that your application does indeed behave correctly and
with improved performance.
-->
<thread_safe_write>false</thread_safe_write>
</batch>
<writer_data_lifecycle>
<autodispose_unregistered_instances>false</autodispose_unregistered_instances>
</writer_data_lifecycle>
</datawriter_qos>
<!-- === DataReader Configuration: ================================= -->
<!--
The base configuration of the DataReader object that consumes throughput
data (the -sub side of the application).
This element corresponds to the DataReaderQos type, which is described
in detail in the API Reference HTML documentation. Each child element
corresponds to a field in that structure with the same name. Any
parameter not listed here will pick up the documented default value.
-->
<datareader_qos>
<!--
Setting history.kind = KEEP_ALL, Connext will attempt to maintain
and deliver all the values of the instance to existing subscribers.
The resources that Connext can use to keep this history are limited
by the settings of the RESOURCE_LIMITS.
-->
<history>
<kind>KEEP_ALL_HISTORY_QOS</kind>
</history>
<!--
Setting reliability.kind = RELIABLE_RELIABILITY_QOS, data samples
originating from a single DataWriter cannot be made available to the
DataReader if there are previous data samples that have not been
received yet due to a communication error.
The default value of reliability.kind is RELIABLE_RELIABILITY_QOS.
The reliability.kind can be modified to BEST_EFFORT_RELIABILITY_QOS
by using the command-line option -bestEffort.
-->
<reliability>
<kind>RELIABLE_RELIABILITY_QOS</kind>
</reliability>
<!--
DurabilityQos policy specifies whether or not Connext will store and
deliver previously published data samples to new DataReaders
that join the network later.
Important: durability.kind and durability.direct_communication are configured
automatically within the source code. To modify them, use the input commands
-durability and -noDirectCommunication.
The default value of _DirectCommunication is true.
The default value of _Durability is DDS_VOLATILE_DURABILITY_QOS.
<durability>
<kind>_Durability</kind>
<direct_communication>_DirectCommunication</direct_communication>
</durability>
-->
<resource_limits>
<!--
The initial and maximum number of data samples. The middleware will
make sure to allocate space for the initial_samples, and then if
needed, it will grow the allocated memory up to a point where it
supports max_samples.
For the initial number of samples we choose a number that should be
enough for most use-cases (therefore no need to grow), but that
should not affect the memory consumption by reserving too much
memory.
-->
<max_samples>10000</max_samples>
<initial_samples>128</initial_samples>
<!--
The maximum number of samples that can be stored for a single
instance. If the throughput topic is not keyed, there is only a
single instance, so this value should always be set the same
as max_samples.
For a keyed topic, you might want to use this parameter to institute
a degree of "fairness" among the instances.
-->
<max_samples_per_instance>10000</max_samples_per_instance>
</resource_limits>
<reader_resource_limits>
<!--
The maximum number of samples that Connext will store from a
single DataWriter. If you run this application with only a single
DataWriter (that is, in a one-to-one or one-to-many configuration),
there is no reason for this value to be set to anything less than
max_samples. If you have many writers and need to institute
a degree of "fairness" among them, you can decrease this value.
-->
<max_samples_per_remote_writer>10000</max_samples_per_remote_writer>
<!--
The maximum number of data samples that the application can receive
from Connext in a single call to DataReader::read() or
take(). If more data exists in the middleware, the application will
need to issue multiple read()/take() calls.
When reading data using listeners, the expected number of samples
available for delivery in a single take() call is typically small:
usually just one in the case of unbatched data, or the number of
samples in a single batch in the case of batched data. When polling
for data or using Waitsets, however, multiple samples (or batches)
could be retrieved at once, depending on the data rate.
A larger value for this parameter makes the API simpler to use, at
the expense of some additional memory consumption.
-->
<max_samples_per_read>65536</max_samples_per_read>
</reader_resource_limits>
<protocol>
<rtps_reliable_reader>
<!--
When the DataReader receives a heartbeat from a DataWriter
(indicating (a) that the DataWriter still exists on the network
and (b) what sequence numbers it has published), the following
parameters indicate how long it will wait before replying with
a positive (assuming they aren't disabled) or negative
acknowledgement.
The time the reader waits will be a random duration between
the minimum and maximum values. Narrowing this range, and shifting
it towards zero, will make the system more reactive. However, it
increases the chance of (N)ACK spikes. The higher the fanout in
your system (i.e., the number of readers per writer), the more
you should consider specifying a range here.
-->
<min_heartbeat_response_delay>
<sec>DURATION_ZERO_SEC</sec>
<nanosec>DURATION_ZERO_NSEC</nanosec>
</min_heartbeat_response_delay>
<max_heartbeat_response_delay>
<sec>DURATION_ZERO_SEC</sec>
<nanosec>DURATION_ZERO_NSEC</nanosec>
</max_heartbeat_response_delay>
</rtps_reliable_reader>
</protocol>
</datareader_qos>
</qos_profile>
<!-- ================================================================= -->
<!-- Latency QoS Profile -->
<!-- ================================================================= -->
<!--
This profile is used by the latency-testing portion of the application,
provided that positive acknowledgements have not been disabled with the
'-noPositiveAcks' command-line argument or 'use positive acks = false'
INI file configuration.
-->
<qos_profile name="LatencyQos" base_name="BaseProfileQos">
<!-- === DataWriter Configuration: =================================
The base configuration of the DataWriter object that consumes latency
data (on the -sub side of the application).
This element corresponds to the DataWriterQos type, which is described
in detail in the API Reference HTML documentation. Each child element
corresponds to a field in that structure with the same name. Any
parameter not listed here will pick up the documented default value.
-->
<datawriter_qos>
<!--
Setting history.kind = KEEP_ALL, Connext will attempt to maintain
and deliver all the values of the instance to existing subscribers.
The resources that Connext can use to keep this history are limited
by the settings of the RESOURCE_LIMITS.
-->
<history>
<kind>KEEP_ALL_HISTORY_QOS</kind>
</history>
<!--
Setting reliability.kind = RELIABLE_RELIABILITY_QOS, data samples
originating from a single DataWriter cannot be made available to the
DataReader if there are previous data samples that have not been
received yet due to a communication error.
The default value is RELIABLE_RELIABILITY_QOS.
It can be modified to BEST_EFFORT_RELIABILITY_QOS
using the command-line option -bestEffort.
-->
<reliability>
<kind>RELIABLE_RELIABILITY_QOS</kind>
<max_blocking_time>
<sec>DURATION_INFINITE_SEC</sec>
<nanosec>DURATION_INFINITE_NSEC</nanosec>
</max_blocking_time>
</reliability>
<!--
The Durability QoS policy specifies whether or not Connext will store and
deliver previously published data samples to new DataReaders that join the
network later.
Important: durability.kind and durability.direct_communication are configured
automatically within the source code. To modify them, use the input commands
-durability and -noDirectCommunication.
The default value of _DirectCommunication is true.
The default value of _Durability is DDS_VOLATILE_DURABILITY_QOS
if _DirectCommunication is false
if _Durability is DDS_TRANSIENT_DURABILITY_QOS or DDS_PERSISTENT_DURABILITY_QOS
<durability>
<kind>_Durability</kind>
<direct_communication>_DirectCommunication</direct_communication>
</durability>
-->
<!--
The number of samples for which Connext will set aside space.
See the comments above for more information.
-->
<resource_limits>
<max_samples>LENGTH_UNLIMITED</max_samples>
<initial_samples>100</initial_samples>
<max_samples_per_instance>LENGTH_UNLIMITED</max_samples_per_instance>
</resource_limits>
<!--
The behavioral contract under which the DataWriter will carry out the
reliability protocol. See the comments above for more information.
-->
<protocol>
<rtps_reliable_writer>
<low_watermark>10</low_watermark>
<high_watermark>100</high_watermark>
<heartbeats_per_max_samples>1000</heartbeats_per_max_samples>
<heartbeat_period>
<sec>DURATION_ZERO_SEC</sec>
<nanosec>10000000</nanosec>
</heartbeat_period>
<fast_heartbeat_period>
<sec>DURATION_ZERO_SEC</sec>
<nanosec>1000000</nanosec>
</fast_heartbeat_period>
<late_joiner_heartbeat_period>
<sec>DURATION_ZERO_SEC</sec>
<nanosec>10000000</nanosec>
</late_joiner_heartbeat_period>
<max_heartbeat_retries>LENGTH_UNLIMITED</max_heartbeat_retries>
<min_nack_response_delay>
<sec>DURATION_ZERO_SEC</sec>
<nanosec>DURATION_ZERO_NSEC</nanosec>
</min_nack_response_delay>
<max_nack_response_delay>
<sec>DURATION_ZERO_SEC</sec>
<nanosec>DURATION_ZERO_NSEC</nanosec>
</max_nack_response_delay>
<min_send_window_size>LENGTH_UNLIMITED</min_send_window_size>
<max_send_window_size>LENGTH_UNLIMITED</max_send_window_size>
</rtps_reliable_writer>
</protocol>
<writer_data_lifecycle>
<autodispose_unregistered_instances>false</autodispose_unregistered_instances>
</writer_data_lifecycle>
</datawriter_qos>
<!-- === DataReader Configuration: =================================
The base configuration of the DataReader object that consumes latency
data (on the -pub side of the application).
This element corresponds to the DataReaderQos type, which is described
in detail in the API Reference HTML documentation. Each child element
corresponds to a field in that structure with the same name. Any
parameter not listed here will pick up the documented default value.
-->
<datareader_qos>
<!--
The default value of reliability.kind is RELIABLE_RELIABILITY_QOS.
The reliability.kind can be modified to BEST_EFFORT_RELIABILITY_QOS
by using the command-line option -bestEffort.
-->
<reliability>
<kind>RELIABLE_RELIABILITY_QOS</kind>
</reliability>
<!--
DurabilityQos policy specifies whether or not Connext will store and
deliver previously published data samples to new DDSDataReader entities
that join the network later.
Important: durability.kind and durability.direct_communication are configured
automatically within the source code. To modify them, use the input commands
-durability and -noDirectCommunication.