Datasheets

Modules
	Datasheet for armv6vfphLinux3.xgcc4.7.2

---

Detailed Description

Introduction

This document provide metrics for the RTI Connext DDS Micro libraries. The information contained here is only meant as guidance and actual numbers will vary across different hardware and compilers. Please note that the numbers are generated before the final release and the source-code line count and library sizes may vary slightly. Performance numbers are always valid for the final release. Datasheets are provided for the following two platforms:

• Raspberry Pi Model B+ datasheet_armv6leLinux2_6gcc4_6_3

Understanding the Datasheet Information

The following information is gathered for each architecture with a data-sheet:

• Source Line Count
• Library Size Information
• Heap Usage Information
• Thread Memory
• Throughput Measurements
• Round-trip Latency Measurements

This section provides information on how to interpret this information.

Source Line Count

The "Source Line Count" section gives the size of each library in terms off effective lines of source-code (ELOC) and is gathered from the pre-processed files for the release library only. The ELOC number only include lines with source that directly contribute to the object-files. For example, the following are not included:

• comments
• white-space
• lines with only braces
• type, structure, constant definitions

The ELOC number by itself is not very useful, but is provided since it is a frequently asked question.

Library Size Information

The "Library Size" section gives the size of each shared library's text,bss and data segment in bytes. This number is retrieved using the GCC size command on Linux.

Heap Usage Information

The "Heap" section provides information about how much dynamically allocated memory is used by RTI Connext DDS Micro. It should be noted that exact numbers are very difficult to estimate and that the numbers should used as guidance. Please refer to Introduction for a more information on resource-limits and memory usage.

On Linux, for each heap allocation using malloc, malloc_usable_size() is called to determine the actual size of each allocation. The numbers include resources used by the RH_SM, WH_SM, and UDP components, but not the resources used by the dynamic discovery component (DPDE) or the static discovery component (DPSE). In addition, please note that the memory does not include memory for the actual user-data. This must be added according to the resource-limits.

Two tables are provided: one for debug libraries and one for release libraries. The size for entities that are controlled by resource-limits are provided. In addition, a formula is provided to estimate the amount of memory used by a data-reader and data-writer as these are typically the ones that consume most of the memory. The following short-hands are used in these formulas:

• rl_ms - resource_limits.max_samples
• rl_mi - resource_limits.max_instances
• rl_mrw - datareader_resource_limits.max_remote_writers
• rl_mrpw - datareader_resource_limits.max_routes_per_writer
• wrl_mrw - datawriter_resource_limits.max_remote_readers
• wrl_mrpr - datawriter_resource_limits.max_routes_per_reader

Throughput Measurements

The throughput is measured between two identical machines using the test configuration is shown below.

  +-----------+                           +----------+
  |           |                           |          |
  |  Sender   +----------Sample --------->| Receiver |
  |           |                           |          |
  +-----------+                           +----------+

Interpretation of the measurements:

• Size - The size of the DDS sample payload (UDP overhead is not included)
• Demand - How many samples of the given size is written in a burst before a short delay (10ms). For example, a demand of 110 means that 110 samples are written in a burst followed by a 10ms delay before 110 samples is written again. This burst-delay-burst cycle continues for 1s before a new round is started.
• Samples - The number of samples written.
• Samples/sec - The number of samples written per second.
• Mbit/s - The bandwidth utilization for the payload based on Size and Samples/sec.
• Samples Lost - On the subscriber size the number of samples received is counted against what is expected.
• Samples Rejected - OLn the subscriber size the number of samples rejected by DDS is counted.
• CPU - The CPU load reached during a test. Note that how the CPU load is measured varies between platforms and is an approximation.
• Memory - The total amount of memory used during the test. This number should be constant as RTI Connext DDS Micro allocates all memory at creation time.

Round-trip Latency Measurements

The round-trip latency is measured between two identical machines using the test configuration is shown below.

  +-----------+                           +--------+
  |           +----- PING --------------->|        |
  |  Sender   |                           | Echoer |
  |           |<-----PONG ----------------+        |
  +-----------+                           +--------+

The latency is measured by sending one PING sample and wait for the Echoer to return the PONG sample. The sender then records the time it took to receive the PONG sample. The test is repeated a number of times for each size. Note that it is the round-trip latency that is measured.

Interpretation of the measurements (all numbers are reported in micro-seconds):

• Size The size of the DDS sample payload (UDP overhead is not included)
• Std Dev Standard deviation
• Mean The mean round-trip latency
• Min The minimum round-trip latency
• 50% The 50th percentile round-trip latency
• 90% The 90th percentile round-trip latency
• 99% The 99th percentile round-trip latency
• 99.99% The 99.99th percentile round-trip latency
• Max The maximum round-trip latency

Dynamic Discovery (DPDE) Heap Usage Information

The DPDE plugin is a DDS application that advertises locally created DDS entities and listens for DDS entities available in the DDS data-space. It is implemented using the DDS APIs supported by RTI Connext DDS Micro.

The DPDE plugin creates the following DDS entities:

• One DDS Publisher
• One DDS Subscriber
• Three DDS Topics
• Three DDS DataReaders
• Three DDS DataWriters

The DPDE plugin also registers the following three types:

• DDS_ParticipantBuiltinTopicData
• DDS_PublicationBuiltinTopicData
• DDS_SubscriptionBuiltinTopicData

All heap memory allocated by the DPDE plugin is allocated after the DDS DomainParticipant is created (no additional memory is allocated after the DDS DomainParticipant is enabled).

Static Discovery (DPSE) Heap Usage Information

The DPSE plugin is a DDS application that only advertises locally created DDS DomainParticipants and listens for other DDS DomainParticipants available in the DDS data-space. It is implemented using the DDS APIs supported by RTI Connext DDS Micro.

The DPSE plugin creates the following DDS entities:

• One DDS Publisher
• One DDS Subscriber
• One DDS Topics
• One DDS DataReader
• One DDS DataWriter

The DPSE plugin also registers the following type:

• DDS_ParticipantBuiltinTopicData

All heap memory allocated by the DPSE plugin is allocated after the DDS DomainParticipant is created (no additional memory is allocated after the DDS DomainParticipant is enabled).

Thread Memory

RTI Connext Micro uses multiple threads. The timer thread is managed by the domain participant and cannot easily be removed. All the UDP threads are managed by the UDP transport and a different UDP transport implementation can choose a different threading model.

Thread	Heap	Default Stack(1)
Timer	N/A	16384
UDP Receive	8192 (2)	16384

• (1) - The "Default Stack" is the stack size a thread is created with. It is not the maximum stack size needed at run-time based on the deepest call-path.
• (2) - This is the default maximum message size property. Each UDP thread allocates its own receive buffer.