This video https://youtu.be/TBrPyy48vFI?t=1277 is a few years old, but it covers how the GRiSP platform combines Erlang and RTEMS Real-time OS [1] to overcome Erlang VM's soft real-time limitations and achieve hard real-time event handling.
What are the soft real time limitations of erlang?
im_down_w_otp · 4h ago
Erlang's BEAM, assuming no chicanery of NIFs, will use reduction counting to eventually yield a scheduler to make sure other Erlang processes get execution time. This gives you kind of a "will eventually happen" property. It can't guarantee meeting a deadline. Just that all things will be serviced at some point.
elcritch · 2h ago
Right GRiSP has support for creating RTOS tasks in C, IIRC.
Within BEAM itself there’s no priority mechanism, however, on a RPi3 or BeagleBone you could get about an 200 uS average response time to GPIO on Linux, even under moderate load. The jitter was pretty low too, like 10-20 uS on average, but the 99.9% tail latencies could get up to hundreds of millis.
That’s fine for many use cases. Still I now prefer programming on esp32’s with Nim for anything realtime. Imperative programming just makes handling arrays easier. Just wish FreeRTOS tasks had error handling akin to OTP supervisors.
Now Beam/Elixir would be amazing for something like HomeAssistant or large networked control systems.
harrisi · 1h ago
Erlang does have a mechanism to modify process priority, with process_flag/2,3.
As of OTP 28 there's also priority messaging that a process can opt in to. Not really related, but it's new and interesting to note.
kristianp · 5h ago
I suppose having the small DRAM footprint is required to meet extremely low power requirements. How low power is it? The CPU has a 18.6 μA/MHz Run mode at 3.3 V [1], so 61μW! I wanted to know more about the power harvesting applications though.
[1] https://www.rtems.org/
Within BEAM itself there’s no priority mechanism, however, on a RPi3 or BeagleBone you could get about an 200 uS average response time to GPIO on Linux, even under moderate load. The jitter was pretty low too, like 10-20 uS on average, but the 99.9% tail latencies could get up to hundreds of millis.
That’s fine for many use cases. Still I now prefer programming on esp32’s with Nim for anything realtime. Imperative programming just makes handling arrays easier. Just wish FreeRTOS tasks had error handling akin to OTP supervisors.
Now Beam/Elixir would be amazing for something like HomeAssistant or large networked control systems.
As of OTP 28 there's also priority messaging that a process can opt in to. Not really related, but it's new and interesting to note.
[1] https://www.st.com/resource/en/datasheet/stm32u5f7vj.pdf
No comments yet