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

[Joe Armstrong]

Hard real time: All requests MUST be satisfied within a specified time.
Note this does not mean fast. If the deadline is five years and you respond
with a year it's hard real time :-)

Soft real time: Some requests might miss the deadlines.

Fast hard real time is really difficult. Here you'll need special
purpose hardware, a custom OS and a special programming language.

The programming language must be constructed so that you can prove
assertions about the worse case execution time of code. The OS must not
introduce unexpected delays, and the hardware must have predictable delays.

Hard real time is mostly associated with hardware control -  examples:
Braking systems in cars, control system in unstable aircraft, pulling
out fuel rods in a nuclear reactor if things go wrong.

In the software world, hard real time usually means "fast with
predictable delays" (but peoples idea of what is fast varies)

Erlang was designed for programming telephone exchanges - we wanted
response times of milliseconds for simple requests. We also didn't want
long lived computations to block computations that could be performed
immediately - so each process gets an equal time slice of the CPU.

Telecoms protocols are designed with failure in mind - so if the odd
deadline is missed the system just tries again.

My mental model of a telecomms system is that we have tens to hundreds
of thousands of long-lived connections. Each of these sleeps for a
very long
time (from the computer's point of view) then wakes up and requests a
computation which takes (from the computer's point of view) a very
small time.

This is what Erlang was designed for - hundreds of thousands of processes
that are largely inactive - then they wake up and request a small
amount of computation. The odd process might request a large amount of
processing
but this should not block the other processes. Also some processes will fail,
due to software errors, the errors should be logged and not damage the
unfailing parts of the system. Responses times should be of the order
of milliseconds.

This model works pretty well for large multiplexing web-servers (like
WhatsApp) - the VM has be designed for fast context switching,
fast process creation and fast message passing and have process
isolation and be non-blocking.

/Joe





On Fri, Oct 20, 2017 at 3:58 PM, Avinash Dhumane <nistrigunya@REDACTED> wrote:
> Hello!
>
> The application runs directly on latest Intel Xeon.
>
> The source code of specific module in question is emailed to you separately.
>
> There is a process per instance of "algorithm trading strategy", but no two
> processes share anything except the ordering socket to the market, which is
> accessed through synchronization (ETS). But, during the market test, we run
> only one or two strategies so there is no synchronization overhead.
>
> The major computation is market depth update and price matching.
>
> On Fri, Oct 20, 2017 at 6:55 PM, Aleksander Nycz
> <Aleksander.Nycz@REDACTED> wrote:
>>
>> Hello,
>>
>>
>> My private definition:
>>
>> Hard real time -> 100% requests/jobs/processes must be completed before
>> deadline
>>
>> Soft real time -> N% requests/jobs/processes must be completed before
>> deadline, where N < 100%,
>>
>>     so we can/must accept that some jobs will not be finished on time.
>>
>>
>> And few question:
>>
>> 1. Erlang VM is running on Virtual Machine on bare metal?
>>
>> 2. What you erlang process really do? Can you show us some code?
>>
>>
>> Regards
>>
>> Aleksander Nycz
>>
>>
>> W dniu 2017-10-20 o 14:00, Avinash Dhumane pisze:
>>
>> 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
>>
>>
>> --
>> Aleksander Nycz
>> Chief Designer
>> Telco_021 BSS R&D
>> Comarch SA
>> Phone:  +48 17 785 5909
>> Mobile: +48 691 464 275
>> website: www.comarch.pl
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>