You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I haven't managed to get memory profiling to work with RNS (entirely my fault, I'm sure, I've never done memory profiling in Python) but the large memory footprint on Linux would be a problem on embedded systems. Based on my (above average but still lacking) knowledge of the workings of RNS, I consider the primary use of memory to be the dictionaries that store data, including keys, destination hashes, and other per-destination information. Current SBCs can handle the memory requirements, but this ends up causing a number of issues towards pure embedded mobile systems, including availability, cost, size, power consumption, and unneeded complexity.
Moving to a transactional database will slow the lookups down, but can solve memory related scaling problems. How much slower, and if this is acceptable (and if it can be mitigated with caching) is a major discussion and testing point. It may or may not be a good idea on non-embedded systems.
However, offloading memory to storage can be a huge boon to embedded systems. The problem quickly becomes that embedded systems do not support most transactional databases (as a server). One exception is SQLite, which is supported on most microcontrollers explicitly to run a transactional database on an SD card. It's likely the 512K RAM on the ESP32 wouldn't be enough in general, but PSRAM could bring this up to at least 4M which may be enough breathing room for core functions, but the ability to drop in several gigabytes of flash memory (example: the SD card mentioned above) at minimal cost could be the difference between a functional RNS implementation on an embedded system and an impossible task.
Anyone with more experience in embedded systems have an opinion?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I haven't managed to get memory profiling to work with RNS (entirely my fault, I'm sure, I've never done memory profiling in Python) but the large memory footprint on Linux would be a problem on embedded systems. Based on my (above average but still lacking) knowledge of the workings of RNS, I consider the primary use of memory to be the dictionaries that store data, including keys, destination hashes, and other per-destination information. Current SBCs can handle the memory requirements, but this ends up causing a number of issues towards pure embedded mobile systems, including availability, cost, size, power consumption, and unneeded complexity.
Moving to a transactional database will slow the lookups down, but can solve memory related scaling problems. How much slower, and if this is acceptable (and if it can be mitigated with caching) is a major discussion and testing point. It may or may not be a good idea on non-embedded systems.
However, offloading memory to storage can be a huge boon to embedded systems. The problem quickly becomes that embedded systems do not support most transactional databases (as a server). One exception is SQLite, which is supported on most microcontrollers explicitly to run a transactional database on an SD card. It's likely the 512K RAM on the ESP32 wouldn't be enough in general, but PSRAM could bring this up to at least 4M which may be enough breathing room for core functions, but the ability to drop in several gigabytes of flash memory (example: the SD card mentioned above) at minimal cost could be the difference between a functional RNS implementation on an embedded system and an impossible task.
Anyone with more experience in embedded systems have an opinion?
Beta Was this translation helpful? Give feedback.
All reactions