RTI Connext DDS Micro  Version 2.4.8
 All Data Structures Files Functions Variables Typedefs Enumerations Enumerator Macros Groups Pages
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.

MicroMemoryMap.png
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 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 2350 The sample and instance resources must be added.
local_writer_allocation 2450 The sample and instance resources must be added.
matching_writer_reader_pair_allocation 29
remote_participant_allocation 597
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 256
(DataReader) max_samples 152
(DataReader) max_remote_writers 364
(DataReader) max_routes_per_writer 83
(DataWriter) max_instances 73
(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

RTI Connext DDS Micro Version 2.4.8 Copyright © Tue Apr 12 2016 Real-Time Innovations, Inc