<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>"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.<br>
</p>
<p>"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.</p>
<p>Another term you'll sometimes come across is "near real time" -
which tends to imply that a little delay is tolerable.</p>
<p>More generally, "hard real time" is exactly that. Everything
else involves loosened constraints.</p>
<p>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.<br>
</p>
<p>Miles Fidelman<br>
</p>
<br>
<div class="moz-cite-prefix">On 10/20/17 8:00 AM, Avinash Dhumane
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGPCG6WTcQeTKxxEUz_EVz6bK0MAePOuBB03aE_VHb_n574LjQ@mail.gmail.com">
<div dir="ltr">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).
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thanks.</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
erlang-questions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra</pre>
</body>
</html>