[erlang-questions] Making erlang more realtime?
Thu Mar 2 22:49:58 CET 2017
Probably it does not help an awful lot, but I recall an interesting project
from couple of years ago called erlyvideo (later flussonic). I believe they
have been busy with a similar challenge (video streaming with Erlang) and
put a lot of work into tweaking performance. Perhaps you can still find
interesting hints and discussions in the mailing list archive (or
elsewhere) when searching for this project.
On 2 March 2017 at 21:26, Dmytro Lytovchenko <dmytro.lytovchenko@REDACTED>
> Making it "more realtime" has little sense, as it is not realtime platform
> and never was, and never intended to be.
> A few points to consider.
> 1. Erlang is not a realtime platform, i.e. it does not give you
> millisecond/microsecond guarantees. It is soft realtime, which guarantees
> that your code will eventually and periodically get CPU time with some +/-
> 100 ms precision depending on the current load.
> 2. If you want such millisecond precision you could write the critical
> decoding/feeding part in native code with an appropriate tool such as
> C/C++/Rust/Ocaml/Java/C# etc while Erlang will do the rest of the
> management and orchestration in your system.
> 3. One more way would be to let Erlang decode video ahead of time, so that
> you have few frames ready and cached for such a hiccup moment. Then even if
> some frame is late, there is always another frame ready to cover for it.
> Then let video player smooth the hiccups. I think streaming services do
> this at the cost of significant caching ahead.
> 2017-03-02 21:17 GMT+01:00 Vans S <vans_163@REDACTED>:
>> I currently need to stream 60 frames per second of video and I made a
>> simple test case using erlang.
>> I have 1 gen_server doing a erlang:send_after every 17ms, when the
>> handle_info procs it calls
>> os:perf_counter(1000) then compares the last time to the current, if the
>> difference is > 20,
>> print to console.
>> Iv noticed that about every 2-3 seconds, the send_after arrives around in
>> 20-23ms, this is not
>> respecting the millisecond realtime nature that I thought Erlang can
>> Is there any VM arguments that could be passed to increase the realtime
>> properties or other
>> things that can be done?
>> The testcase is just a naked rebar app with 1 gen_server not doing
>> anything else.
>> erlang-questions mailing list
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions