[erlang-questions] What does "soft" real-time mean?
Sat Oct 21 16:08:06 CEST 2017
"Hard real time" generally refers to things where exact timing matters -
things like machine control, sensor-to-weapon linkages, autopilots,
software-defined radio, and such. As some definitions put it, missing a
deadline is considered a system failure. Generally, hard real time code
involves direct hardware access, referenced to real-time clocks, and you
can't miss any events.
"Soft real time" generally refers to things that are still "real-time"
but where things are "looser." For example, VoIP is time sensitive, but
can tolerate the occasional lost packet. Other kinds of soft real-time
can tolerate a little jitter in the timing.
Another term you'll sometimes come across is "near real time" - which
tends to imply that a little delay is tolerable.
More generally, "hard real time" is exactly that. Everything else
involves loosened constraints.
When it comes to languages & run-times, anything that relies on
asynchronous operating system services is not going to support hard
real-time. Hard real-time generally requires that software run very
close to bare iron, with complete control of the hardware (i.e, no
interrupts, no pre-emption), and access to very accurate timing data.
Erlang is known for high performance, but is very far from able to
support hard real-time.
On 10/20/17 8:00 AM, Avinash Dhumane wrote:
> I have programmed high-frequency trading application in Erlang and
> comparing its reaction performance in the live market with other
> competing applications (mostly, in C).
> It has been a consistent observation that my Erlang application lags
> substantially behind the competing applications. In fact, it never
> matched the reaction time of the so-called "slowest" C application in
> the market.
> The benchmark reaction time is about 5 microseconds. It is the time
> elapsed between tick to order. That is, the difference between the
> timestamps when I receive the tick (market event) from the mailbox of
> my process and when I submit the TCP send call on my order.
> My process maintains the market depths of the securities and when my
> desired price (as a function of best buyers and/or sellers on multiple
> legs of the order) is observed, I compute the order terms and submit.
> The entire computation and communication (with the market) takes place
> within the single process and there are no collaborating processes
> (hence, no inter-process messaging; not even ETS). Still, the reaction
> time is in the order of 20 to 60 microseconds - that is, nowhere
> closer to the benchmark reaction time (5 microseconds).
> 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.
> erlang-questions mailing list
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions