Configuring Resource Limits

Modules
	DomainParticipantFactoryQos
	DomainParticipantQos
	DataReaderQos
	DataWriterQos
	OSAPI
	UDP Transport
	Dynamic Participant Static Endpoint (DPSE)
	Dynamic Participant Dynamic Endpoint (DPDE)

---

Detailed Description

Introduction

RTI Connext DDS Micro is designed for use in real-time systems and uses a predictable and deterministic memory manager to ensure that memory growth is not unbounded, OS memory fragmentation is eliminated and memory usage can be determined a-priori. The advantage with this design is that proper operation is ensured as soon as steady state has been reached. However, it also places an additional burden on the system designer to properly configure each resource-limit. The purpose of this document is to describe all resource-limits in RTI Connext DDS Micro, what the behavioral impact is, and what the impact on memory usage is.

Dynamic Memory Allocation

RTI Connext DDS Micro allocates heap memory to create internal data-structures. It is important to know that RTI Connext DDS Micro manages memory allocated from the system heap using its own internal memory management, and only returns memory allocated from the system back to the system when something is deleted. That is, if an application never deletes anything, no memory is returned to the system.

As a rule of thumb, in RTI Connext DDS Micro only APIs that end in _create() or _new() allocate heap memory and APIs that end in _delete() or _free() frees memory. An exception to this rule is dynamic discovery which allocates memory at run-time for the topic and type names.

RTI Connext DDS Micro does not support dynamically allocating resources beyond the initial configuration. That is, all resource limits must be finite. This restriction may be removed in a future version.

Memory Model

All resource-limits in RTI Connext DDS Micro is specified in a Qos policy or property. The figure below illustrates where the various resource-limits are applied, and the following sections describe each user adjustable resource-limit in more detail. All numbers in blue corresponds to a resource-limit.

The memory used by each resource-limit and where they apply

It is important to know that while the numbers are measured by running tests it is very difficult to find exact formulas. Thus, the numbers must be used as guidelines when designing an application.

Please refer to the Reference Manuals for default values for each resource-limit and to Datasheets for more information on metrics. The numbers listed below are based on Linux release libraries, but should not vary significantly for other platforms.

Resource-limit	Size in Bytes	Notes
DomainParticipantFactory	6600
max_participants	13600	This is the memory for an empty participant. The memory used by each entity must be added as described for each entity.
max_components	N/A
local_topic_allocation	117	Add strlen(topic_name) + 1
local_type_allocation	13	Add strlen(type_name) + 1
local_publisher_allocation	269
local_subscriber_allocation	261
local_reader_allocation	2495	The sample and instance resources must be added.
local_writer_allocation	2524	The sample and instance resources must be added.
matching_writer_reader_pair_allocation	29
remote_participant_allocation	502
remote_writer_allocation	about 600	This includes the topic_name
remote_reader_allocation	about 600	This includes the topic_name
max_destination_ports	78
max_receive_ports	361
(DataReader) max_instances	272
(DataReader) max_samples	160
(DataReader) max_remote_writers	387
(DataReader) max_routes_per_writer	83
(DataReader) max_samples_per_instance	0
(DataReader) max_remote_writers_per_instance	0
(DataReader) max_samples_per_remote_writer	0
(DataWriter) max_instances	79
(DataWriter) max_samples	116
(DataWriter) max_remote_readers	387
(DataWriter) max_routes_per_reader	83
(DataWriter) max_samples_per_instance	0
max_locators_per_discovered_participant	83
max_buffer_size	0
max_message_size	0
matching_reader_writer_pair_allocation	0