[erlang-questions] What does "soft" real-time mean?

[Jesper Louis Andersen]

On Fri, Oct 20, 2017 at 3:12 PM Avinash Dhumane <nistrigunya@REDACTED>
wrote:

> What I wish to hear from the experienced people on this forum here is
> whether I am missing on something in my Erlang code, or should I just go
> ahead and program in C.
>
>
Your problem is one where you want to have a language which can execute
computations quickly, and preferably well under 1ms. In that case, you
often want explicit concurrency modeling as well as fast computation.
Languages such a C, C++, Rust and OCaml are good candidates.

Soft realtime isn't that well-defined in the literature. But one can define
it from hard realtime. Other people have already written about what hard
realtime is, so I'm not going to bother with that. But I do note one thing
about hard-realtime systems in the context of concurrency which I want to
make:

If you have an existing schedule of processes, and you want to add a new
one, you must say how often you want to be called, and for how long you
will run. Now, the system can either accept your process, in which case it
must fulfill the periodic schedulings you wanted. If you use too much time,
it is valid for the system to kill your process. Importantly, if the
scheduler cannot fit you into its schedule, it must reject starting your
process. So if you ask that 10000 processes be started at the same point in
time, the scheduler must reject you, unless it has access to 10000
processor cores.

Now, soft realtime is like hard realtime, but there is an SLA and certain
objectives which must be met. For instance that 99th percentile of all
requests are handled within 2ms. The last percent is ignored and we make no
rules for those. Also note that "soft" realtime is a practical thing: you
measure the system and fail it if it doesn't meet the SLA.

Erlang, as a system is good for handling such soft realtime requirements,
provided that they tend to fall in the millisecond range and that you don't
excessively load the system with work. Then you can stay within the SLA in
practice, easily.

However, if your task is that you want to answer a query in less than a
millisecond, you need something closer to the steel. C is one option, but
note that if you want a nanosecond computation, you probably want to move
from C to FPGAs. Often, you also want explicitly control over what you are
doing. If you hog the core with something else, then even switching away
from the current work to the newly arrived work can be enough to mess with
your timing schedule. Likewise, if the operating system takes an interrupt
at the wrong point in time, your timing will be off.

Hence, a good solution starts by defining the acceptable window of lag
before answering what language to use. At, say, 5us, you have around 20
memory reads from DRAM into cache lines. Tight schedule which requires you
have some control you wont have in a typical Erlang system, even if you
factor out the computation to a NIF. Even in C, this will be hard to get
close to. If your process is switched out, you are looking at TLB misses as
well and it can easily prod you into a direction where you can only answer
in 5us for synthetic benchmarks. The trick, of course, is to "cheat" by
doing more than a single piece of work in say 50us and then divide down to
claim that it is 5us. Or by keeping the data set small enough it fits into
L1 or L2.

Erlang could be a nice tool for the orchestration on top of the C programs
however, if you happen to need some massive concurrency there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171022/4e98dd9a/attachment.htm>