Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.
NDK RAM Sizing: Concerto Example
The TI-RTOS product installation includes a tcpEcho example. You can download the TI-RTOS installer. The example runs on the TMDXDOCKH52C1 (Concerto) board. RAM is limited on this board, so steps were taken to reduce the RAM requirements by the application. The following is a discussion of the actions taken.
The tcpSendReceive host tool in TI-RTOS sends a TCP packet to the specified IP address on a specified port (for example, port 1000). The tcpEcho example echoes that TCP packet back to a host application. This send and echo sequence is repeated until the host application is stopped. Up to 3 host tools can run at the same time. When the host tools attempts to establish the connection, the tcpHandler task in the tcpEcho application creates a new task (tcpWorker), which does the actual echoing. Once the socket is terminated by the host, the tcpWorker terminates also. The size of the TCP payload was 1024 bytes.
Default RAM usage
The following table shows RAM usage based on the number of TCP connections. All sizes are in bytes. The application uses the default SYS/BIOS heap size of 20480.
|# Connections||Memory Manager||Network Packets||Used Heap||Total|
- # Connections: Number of tcpSendReceive sessions running.
- Memory Manager: Statically defined character arrays See NDK Static Internal Memory Manager.
- Network Packets: Statically defined character arrays. See NDK Static Network Buffers.
- Used Heap: Amount of memory that was used in the SYS/BIOS default heap. This includes allocation by non-networking components also. See NDK Dynamic Memory Manager.
Note: The third connection failed because the target was out of memory (OOM).
The amount of heap usage increases by 6328 bytes for each additional connection. Here is where this number comes from:
1024 bytes for new task 2048 bytes for socket Tx Buffer 2048 bytes for socket Rx Buffer 1024 bytes tcpHandler task allocates + 184 bytes miscellaneous (Task Object, etc.) -------------------------------------- 6328 bytes total
RAM usage after modifications
The following changes were made within the .cfg file to reduce the RAM requirements.
By default for M3, M4, and M4F, there are 16 network buffers. Each buffer is 1536 bytes (by default). Since this is a fairly simple application, the number of network packets was reduced to 6.
Global.pktNumFrameBufs = 6;
The risk of reducing the number of packets is greater when a burst (receive or transmit) occurs. In such cases, the packets could all be used, resulting in dropping packets. Since this application uses TCP, the TCP protocol handles the retransmission of dropped packets.
By default for M3, M4, and M4F, there are 8 buckets with the Memory Manager. Each bucket is 3072 bytes (by default). After running the application and looking at _mmCheck results, it was determined that not all the buckets were being used. So the count was reduced to 6.
Global.memRawPageCount = 6;
After running the application, the "Detailed" view of the Task Module in ROV was examined. The stack sizes for the NDK tasks were too large. The following properties were changed to reduce the stack sizes:
Global.ndkThreadStackSize = 1536; Global.lowTaskStackSize = 1024; Global.normTaskStackSize = 1024; Global.highTaskStackSize = 1024;
Additionally, since the application was only sending TCP packets of size 1024, the following properties were changed to further reduce the amount of heap size that was used.
Tcp.transmitBufSize = 1024; Tcp.receiveBufSize = 1024;
Additional SYS/BIOS changes
The "Detailed" view of the Task Module in ROV also showed that the Idle task stack size was too large. The Hwi module in ROV showed that the system stack was also too large. These were reduced by changing the following properties:
Task.idleTaskStackSize = 768; Program.stack = 2048;
After making the above changes, the application was rebuilt and run again. Here are the new numbers:
|# connections||Memory Manager||Network Packets||Used Heap||Total RAM||RAM Saved from default|
The amount of heap usage increased by 4280 bytes for each additional connection. Here is where this number comes from:
1024 bytes for new task 1024 bytes for socket Tx Buffer 1024 bytes for socket Rx Buffer 1024 bytes tcpHandler task allocates + 184 bytes miscellaneous (Task Object, etc.) ------------------------------------- 4280 bytes total
We might have reduced the
Global.memRawPageSize property to 1536. This would save an additional 9216 bytes, but we wanted to keep the application somewhat flexible in case additional functionality was needed (for example, to add an HTTP server).