-
Notifications
You must be signed in to change notification settings - Fork 165
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.
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
Matter v1.3 bridged node how to achieve 100 endpoints to C3 target (CON-1417) #1155
Comments
Switch to S3 and use PSRAM, that is never going to fit on a C3. A C3 is good for making a light bulb, not a complete bridge. You can't add PSRAM to the C3 which is why you need to switch to the S3. |
I think @shubhamdp have some success with 100 endpoints in C3, isn't it? |
@abu-matterize, #1103 (comment) was about just configuring the endpoints in sdkconfig. I did not create each one. Let me give a try and get back on this, |
Sure. The included memory profiling makes senses? Or there is still a room to drag it down for each endpoints? |
I've the cli app modified in a way that |
I work on a fully functioning bridge which includes all of the code needed to make various types of endpoint proxies. It isn't even close to fitting into an S3 without PSRAM. But it also doesn't require 2MB of PSRAM, in total I need about 200KB more RAM than there is in the base chip. Since I can't get a chip with less than 2MB PSRAM I use the extra space for more wifi buffers and code caching. I could probably trim that 200KB down to 100KB but once I added the PSRAM I stopping making a lot of effort to minimize memory consumption. I did try for a long time to avoid moving to PSRAM, but it is too tight. You get into problems like in the other thread where you can't pass the conformance tests because you need more wifi buffers and there isn't enough memory. Basic devices will fit into the chips without PSRAM, but once you start adding stuff it won't fit any more. This is how you are going to fail: #1132 |
While building it with |
I gave a try to
I did not disable the chip shell, and was able to spawn 37 endpoints. Disabling chip shell would help add few more (expecting ~ +10). So, I can see approximately 45 bridged endpoints. But, I'm not sure what is your use-case. Once I hit the limit, device was unusable and I can-not interact it through console. So, If you are trying to build the device supporting many bridged endpoints, then you do not have the RAM left to perform operations. For further optimization you can refer RAM and Flash optimization guide. Also, as mentioned by the @jonsmirl you may run into problems when going through certifications. |
Thanks for your responses @shubhamdp and @jonsmirl Is there any plan to further optimise the memory consumption? as like main is more optimised than release/v1.3 |
Switch to $3 ESP32-S3-N4R2 module instead of $2 ESP32-C3 and you won't have anymore issues with running out of memory. |
We do not have a jot down plan, but we are trying our best to optimize the SDK. There are been few attempts on main towards optimizations (0277732, e4777fa, 0e4cb28). However I do not have actual numbers at hand on main and release/v1.3. I'll see if I can get them and update here. |
Sure. Thanks @shubhamdp |
Using this example (built with Matter v1.3), we tried to achieve 100 endpoints to the C3 target, but failed at 27th endpoint with the
E (326240) chip[CSL]: PacketBuffer: pool EMPTY
error.More log
The above mentioned status is after enabling some memory optimisation configs as shown below:
Memory profile for endpoint counts
After a quick search, found this
Is there any optimisation config we're missing in there to achieve 100 endpoints?
The text was updated successfully, but these errors were encountered: