Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Matter RAM Requirements #9261

Open
doru91 opened this issue Aug 26, 2021 · 3 comments
Open

Matter RAM Requirements #9261

doru91 opened this issue Aug 26, 2021 · 3 comments
Labels
freeRTOS k32w platform stale Stale issue or PR v1.1

Comments

@doru91
Copy link
Contributor

doru91 commented Aug 26, 2021 •
edited by bzbarsky-apple
Loading

On NXP K32W061 (Thread + BLE) I reached a high level of RAM consumption, around 141.5K (Thread FTD). This is distributed as follows:

.heap 61440
bss 75240
.data 1796

HEAP

  • FreeRtos tasks's stacks (which are dynamically allocated) requires around 19.5K of RAM (see the picture below). Fine tuning of the stacks was done using FreeRtos Stack High Watermark feature some time ago.

image

  • The main problem is that immediately after I start the device (no BLE/Thread communication available yet) another 30K (!) of RAM are allocated (see the picture below).
    image

  • At a first glance, the main consumer is the InitServer() function, specifically the initialization of each fabrics requires around ~ 1.4K and there are 16 Fabrics (CHIP_CONFIG_MAX_DEVICE_ADMINS). I guess we don't need 16 Fabrics/device, so I believe this number can be lowered to a more realistic value like 4 Fabrics/device (and we save around 17K of RAM - I see that Qorvo already operated this change). Even with this number:

  1. how many CASE session/device are expected and how much RAM does a CASE session expects?
  2. how many ACL lists do we need to store per device and how much RAM requires a single ACL list?

image

BSS

here are the main consumers:

SECTION: .bss
SECTION: .bss
100% 75240 total
├── 18% 13280 _ZN2ot12gInstanceRawE
├── 14% 10371 memp_memory_PBUF_POOL_base
├── 6% 4620 rwip_heap_non_ret
├── 5% 4096 au8PDM_InternalFlashDataBuffer
├── 5% 4096 au8PDM_SegmentDataBuffer
├── 4% 3080 _ZN4chip3app23sInteractionModelEngineE
├── 4% 2960 _ZN12_GLOBAL__N_18gFabricsE
├── 3% 2128 memHeap
├── 3% 2120 _ZN12_GLOBAL__N_19gSessionsE

  • If the device is downgraded to SED (from FTD) then .bss decreases with around 5K;

  • OPENTHREAD_CONFIG_NUM_MESSAGE_BUFFERS is set to the default 44. Each 10 buffers requires ~1.3K of RAM. I believe it really depends on the Thread device used. For an SED, I see that some vendors choose to set this variable to 10 (so _ZN2ot12gInstanceRawE was decreased with around 4K):

  1. Is there a minimum recommended size for the numbers of buffers if the device is an SED?
  2. Same question if the device is an FTD.
  • if LWIP RAW, LWIP TCPEndpoints are disabled and PBUF_POOL_SIZE is decreased from 8 to 6 then another 3K of .bss can be saved. I see that some vendors operated this change.
  1. Do we need TCP for Matter?
  2. What is the recommended LWIP Pool Size for Matter?

In the end, I believe that the current minimal RAM requirements are pretty high for a Matter device and we need to understand better where each byte of memory is consumed.
@doru91 doru91 changed the title RAM Memory Consumption Matter RAM Requirements Aug 26, 2021
@tcarmelveilleux
Copy link
Contributor

doru91 added a commit to doru91/connectedhomeip that referenced this issue Sep 3, 2021
@doru91
TE5 fixes
967df46 
As described in project-chip#9261
several SRAM optimizations were needed:
* decrease the number of Fabrics to 4 (from 16);
* use OT MTD lib for the E-Lock App (which is an SED);
* decrease the number of OT message buffers to 22(FTD)/10(MTD) - (from 44);
* disable LWIP TCP/RAW/Debug/packet buffers.

Also, fix a bug in KVS where the deletion of some keys was not done properly.

Signed-off-by: Doru Gucea <doru-cristian.gucea@nxp.com>
@doru91 doru91 mentioned this issue Sep 3, 2021
Merged
doru91 added a commit to doru91/connectedhomeip that referenced this issue Sep 3, 2021
@doru91
TE5 fixes
b864100 
As described in project-chip#9261
several SRAM optimizations were needed:
* decrease the number of Fabrics to 4 (from 16);
* use OT MTD lib for the E-Lock App (which is an SED);
* disable LWIP TCP/RAW/Debug/packet buffers.

Also, fix a bug in KVS where the deletion of some keys was not done properly.

Signed-off-by: Doru Gucea <doru-cristian.gucea@nxp.com>
andy31415 pushed a commit that referenced this issue Sep 3, 2021
@doru91
TE5 fixes (#9449)
c688360 
As described in #9261
several SRAM optimizations were needed:
* decrease the number of Fabrics to 4 (from 16);
* use OT MTD lib for the E-Lock App (which is an SED);
* disable LWIP TCP/RAW/Debug/packet buffers.

Also, fix a bug in KVS where the deletion of some keys was not done properly.

Signed-off-by: Doru Gucea <doru-cristian.gucea@nxp.com>
andy31415 pushed a commit that referenced this issue Sep 3, 2021
@doru91 @andreilitvin
TE5 fixes (#9449)
6db59aa 
As described in #9261
several SRAM optimizations were needed:
* decrease the number of Fabrics to 4 (from 16);
* use OT MTD lib for the E-Lock App (which is an SED);
* disable LWIP TCP/RAW/Debug/packet buffers.

Also, fix a bug in KVS where the deletion of some keys was not done properly.

Signed-off-by: Doru Gucea <doru-cristian.gucea@nxp.com>
nikita-s-wrk pushed a commit to nikita-s-wrk/connectedhomeip that referenced this issue Sep 23, 2021
@doru91
TE5 fixes (project-chip#9449)
227ae78 
As described in project-chip#9261
several SRAM optimizations were needed:
* decrease the number of Fabrics to 4 (from 16);
* use OT MTD lib for the E-Lock App (which is an SED);
* disable LWIP TCP/RAW/Debug/packet buffers.

Also, fix a bug in KVS where the deletion of some keys was not done properly.

Signed-off-by: Doru Gucea <doru-cristian.gucea@nxp.com>
@tcarmelveilleux tcarmelveilleux mentioned this issue Jan 24, 2022
Merged
tcarmelveilleux added a commit to tcarmelveilleux/connectedhomeip that referenced this issue May 2, 2022
@tcarmelveilleux
Reduce RAM usage from CHIPDeviceEvent
ad70dac 
- CHIPDeviceEvent has had a historical `InternetConnectivityChange`
  event that embeds a 46 byte string (instead of a 16 byte IPAddress)
  and is *only used for logging* in examples.=
- This event is in a union and is the largest of all the sub-structs,
  therefore forcing max-sized events to that event.

Issue project-chip#9261

This PR:

- Changes the `address` from a string to an IPAddress
- Renames to `ipAddress` to break external clients using this struct
  so that they notice on the next roll to master (usage change is trivial).
- Updates all examples to no longer log the address, since it was only
  logged for IPv4 and not IPv6, and IPv6 is the standard, so if it was
  good enough for IPv6 not to log, it's good enough for IPv4.
- Make IPAddress trivially copyable by removing a non-trivial `operator=` that was actually implementing the
  trivial copy. Upstream OpenWeave code that was the basis for the IPAddress.h file removed it already in late
  2021, > 1.5 years after import (see
  openweave/openweave-core@fbbb01c#diff-33121ed998c085b8dc0026f30f24aaadb8b8b36042e38b449cec15c32c8ba86e)
- Update all platforms that populated the address to use the actual address,
  not the string

Testing done:

- All cert tests pass
- All unit tests pass
@tcarmelveilleux tcarmelveilleux mentioned this issue May 2, 2022
Merged
tcarmelveilleux added a commit that referenced this issue May 2, 2022
@tcarmelveilleux @restyled-commits
Reduce RAM usage from CHIPDeviceEvent (#17959)
769264a 
* Reduce RAM usage from CHIPDeviceEvent

- CHIPDeviceEvent has had a historical `InternetConnectivityChange`
  event that embeds a 46 byte string (instead of a 16 byte IPAddress)
  and is *only used for logging* in examples.=
- This event is in a union and is the largest of all the sub-structs,
  therefore forcing max-sized events to that event.

Issue #9261

This PR:

- Changes the `address` from a string to an IPAddress
- Renames to `ipAddress` to break external clients using this struct
  so that they notice on the next roll to master (usage change is trivial).
- Updates all examples to no longer log the address, since it was only
  logged for IPv4 and not IPv6, and IPv6 is the standard, so if it was
  good enough for IPv6 not to log, it's good enough for IPv4.
- Make IPAddress trivially copyable by removing a non-trivial `operator=` that was actually implementing the
  trivial copy. Upstream OpenWeave code that was the basis for the IPAddress.h file removed it already in late
  2021, > 1.5 years after import (see
  openweave/openweave-core@fbbb01c#diff-33121ed998c085b8dc0026f30f24aaadb8b8b36042e38b449cec15c32c8ba86e)
- Update all platforms that populated the address to use the actual address,
  not the string

Testing done:

- All cert tests pass
- All unit tests pass

* Restyled by clang-format

* Fix CI on newer compilers

* Restyled by clang-format

Co-authored-by: Restyled.io <commits@restyled.io>
tcarmelveilleux added a commit to tcarmelveilleux/connectedhomeip that referenced this issue May 2, 2022
@tcarmelveilleux
[NXP K32W] Save RAM by reducing event queue length
d16b702 
Issue project-chip#9261

- K32W platform ran out of BSS last week
- Current usage is default max 100 events in queue. PR project-chip#17959 already reduced
  the size of each event and saved approx 600 bytes. This PR should reduce it
  further.

- This PR moves max queue size from 100 to 75, which is 25% reduction
  and much larger than some platforms which use 25 (which seems low to me)

- Other Thread platforms like QPG and EFR32 run on 25, so not worried here

Testing done:
- Sanity check on K32W via @doru91
@tcarmelveilleux tcarmelveilleux mentioned this issue May 2, 2022
Merged
andy31415 pushed a commit that referenced this issue May 3, 2022
@tcarmelveilleux
[NXP K32W] Save RAM by reducing event queue length (#17979)
c52dc86 
Issue #9261

- K32W platform ran out of BSS last week
- Current usage is default max 100 events in queue. PR #17959 already reduced
  the size of each event and saved approx 600 bytes. This PR should reduce it
  further.

- This PR moves max queue size from 100 to 75, which is 25% reduction
  and much larger than some platforms which use 25 (which seems low to me)

- Other Thread platforms like QPG and EFR32 run on 25, so not worried here

Testing done:
- Sanity check on K32W via @doru91
@stale
Copy link

stale bot commented Dec 11, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@stale
Copy link

stale bot commented Jun 9, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@stale stale bot added the stale Stale issue or PR label Jun 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
freeRTOS k32w platform stale Stale issue or PR v1.1
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@tcarmelveilleux @andy31415 @doru91 @cecille @woody-apple