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

[Miles Fidelman]

"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.

Miles Fidelman


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.
>
> Thanks.
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171021/c49fa0a3/attachment.htm>