RTI Connext DDS Micro
Version 2.4.6
|
Modules | |
DomainParticipantFactoryQos | |
DomainParticipantQos | |
DataReaderQos | |
DataWriterQos | |
OSAPI | |
UDP Transport | |
Dynamic Participant Static Endpoint (DPSE) | |
Dynamic Participant Dynamic Endpoint (DPDE) | |
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.
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.
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.
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 | 2104 | |
max_participants | 13256 | 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 | 109 | Add strlen(topic_name) + 1 |
local_type_allocation | 13 | Add strlen(type_name) + 1 |
local_publisher_allocation | 253 | |
local_subscriber_allocation | 253 | |
local_reader_allocation | 2351 | The sample and instance resources must be added. |
local_writer_allocation | 2447 | The sample and instance resources must be added. |
matching_writer_reader_pair_allocation | 29 | |
remote_participant_allocation | 598 | |
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 | 346 | |
(DataReader) max_instances | 255 | |
(DataReader) max_samples | 152 | |
(DataReader) max_remote_writers | 364 | |
(DataReader) max_routes_per_writer | 83 | |
(DataWriter) max_instances | 72 | |
(DataWriter) max_samples | 115 | |
(DataWriter) max_remote_readers | 372 | |
(DataWriter) max_routes_per_reader | 83 | |
max_locators_per_discovered_participant | 83 | |
max_locators_per_discovered_participant | 83 |