Openthread stack size

[Di Piazza Alain]

Hi,

We are trying to figure out the memory stack size for OpenThread specially for the RAM.
a) If we have 39kbyte of RAM available (max budget) , can you confirm that we will have enough space even taking into account future Openthread enhancements ?

b) There are several configurations which can be used to tune the OpenThread configuration (For instance usage of Coap feature via the define OPENTHREAD_ENABLE_APPLICATION_COAP, etc.. ). What are the main configuration parameters which have a huge impact on the RAM consumption ? (NCP on/off; Role supported..)

c)  MBDTLS seems to be quite costly in terms of memory, and there are a lot of parameter which can be used to tune this module.
Whether, it uses hardware encryption or not for example can I believe have a big impact on the RAM footprint.

d) Are there some buffers which we may need to enlarge in the future if we want to perform more demanding use cases ?

Thanks a lot,

  

[Jonathan Hui]

All good topics that we plan to document in a build configuration document.  Until then, responses below:

On Wed, Apr 5, 2017 at 9:52 AM, Di Piazza Alain <dipiaz...@gmail.com> wrote:

We are trying to figure out the memory stack size for OpenThread specially for the RAM.
a) If we have 39kbyte of RAM available (max budget) , can you confirm that we will have enough space even taking into account future Openthread enhancements ?

We used the CC2538 to achieve certification, which is limited to 32KB RAM.  I think 39KB RAM should be sufficient going forward.

 

b) There are several configurations which can be used to tune the OpenThread configuration (For instance usage of Coap feature via the define OPENTHREAD_ENABLE_APPLICATION_COAP, etc.. ). What are the main configuration parameters which have a huge impact on the RAM consumption ? (NCP on/off; Role supported..)

Major components can be enabled/disabled using the `./configure` script.  I've copied the relevant help output from `./configure --help` below:

  --enable-ftd            Enable Full Thread Device features [default=no].

  --enable-cli            Enable CLI support [default=no].

  --enable-ncp[=spi|uart] Enable NCP support [default=no].

  --enable-builtin-mbedtls

                          Enable builtin mbedtls [default=yes].

  --enable-commissioner   Enable commissioner support [default=no].

  --enable-joiner         Enable joiner support [default=no].

  --enable-jam-detection  Enable Jam Detection support [default=no].

  --enable-mac-whitelist  Enable MAC whitelist/blacklist support

                          [default=yes].

  --enable-diag           Enable diagnostics support [default=no].

  --enable-legacy         Enable legacy network support [default=no].

  --enable-default-logging

                          Enable default logging support [default=no].

  --enable-cert-log       Enable certification log support [default=no].

  --enable-dhcp6-client   Enable DHCPv6 client support [default=no].

  --enable-dhcp6-server   Enable DHCPv6 server support [default=no].

  --enable-dns-client     Enable DNS client support [default=no].

  --enable-application-coap

                          Enable CoAP to an application.[default=no].

  --enable-raw-link-api   Enable raw link-layer API support [default=yes].

Other configuration parameters (e.g. buffer sizes, protocol constants, etc.) can be found in src/core/openthread-core-default-config.h 

c)  MBDTLS seems to be quite costly in terms of memory, and there are a lot of parameter which can be used to tune this module.
Whether, it uses hardware encryption or not for example can I believe have a big impact on the RAM footprint.

Yes, hardware optimization can help a lot.  You can see some examples of hardware optimizations in the following places:

1) examples/platforms/cc2650

2) nRF5-SDK-for-Thread

d) Are there some buffers which we may need to enlarge in the future if we want to perform more demanding use cases ?

Two of the most important configurations:

1) OPENTHREAD_CONFIG_NUM_MESSAGE_BUFFERS, which defines the message buffer pool size.

2) OPENTHREAD_CONFIG_MAX_CHILDREN, which defines the number of Children an FTD can support.

Hope that helps.

--

Jonathan Hui

 

[Di Piazza Alain]

Thanks very much for your answer.
I have now another question...

Suppose we are using two RAM spaces…
a) RAM_STACK used for the stack
b) RAM_APPLI used for the Application.

The Application uses the OpenThread interface (via the ot_xxx functions) in order to activate the Thread stack.
Even for complex use cases, does the application need to allocate a lot of buffers, and request a lot of “extra memory” ‘outside the “thread stack”?
If we use the default settings for OpenThread and if we don’t use inside OpenThread dynamic memory allocation, what is the ratio RAM_APPLI, RAM_STACK expected. Just a rough idea.

Thanks very much for you answer

[Jonathan Hui]

The application is in full control of how much memory it needs.  A very simple application running on OpenThread may use almost no additional code or RAM above what OpenThread needs.  For example, reading a register and communicating that in a UDP message requires very little resources to implement.

--

Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To post to this group, send email to openthre...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/c85ff3b2-c6aa-453c-b8ab-458917a708a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Di Piazza Alain]

Hi,

Recently, we have recompiled (FTD) the Thread stack and it seems that the RAM space requested has increased quite a lot.

Is the target of 39kB of RAM (mentioned a long time ago in this discussion) still valid ? or do we expect some increase in the coming  OpenThread releases ?

Thanks a lot,

 

[Jonathan Hui]

All Thread 1.1.1 features necessary for Thread Certification still fit comfortably within a CC2538 that provides only 32kB RAM.

Compare the latest commit to one from April 5th, it seems that RAM usage has actually reduced significantly.  See below for the numbers.

commit 4db7278 from Sat Aug 26 23:56:10 2017 -0700

   text   data    bss    dec    hex filename

 218804   4228  23848 246880  3c460 output/cc2538/bin/ot-cli-ftd

commit 94fab38 from Wed Apr 5 19:21:33 2017 -0700

   text   data    bss    dec    hex filename

 215072   4228  27964 247264  3c5e0 output/cc2538/bin/ot-cli-ftd

Can you provide more information on your build configuration, compiler, and the difference RAM utilization numbers by OpenThread you are seeing?

--

Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openthread-users+unsubscribe@googlegroups.com.
To post to this group, send email to openthread-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/2faedf25-9953-4671-81dc-3c37c6a88606%40googlegroups.com.

[Di Piazza Alain]

Good news then.

 

We will go through the memory map and analyse the results and let you know. 

Anyway, Openthread provide some configurable parameters  (OPENTHREAD_CONFIG_NUM_MESSAGE_BUFFERS) which can help us in reducing the memory size if necessary. 

Thanks again