<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
span.DefaultFontHxMailStyle
        {mso-style-name:"Default Font HxMail Style";
        font-family:"Calibri",sans-serif;
        color:windowtext;
        font-weight:normal;
        font-style:normal;
        text-decoration:none none;}
span.gmail-m87837883364534983defaultfonthxmailstyle
        {mso-style-name:gmail-m_87837883364534983defaultfonthxmailstyle;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style></head><body lang=EN-IN link=blue vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>The “tick-to-order” indeed needs to be <i>vertically</i> partitioned so that the ticks (market movements) do not sit in the queue waiting to be attended. More so because the ticks arrive in the bursts; the next microsecond might bring no tick, or just one tick, or ten, or hundred, or might even eight hundred. If we  pick up, off the wire, packet-by-packet (I.e. tick-by-tick) and process sequentially, not only we will lose many of them but the last tick (of the burst) will lose its value by the time it gets attention.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Each tick, to be attended to (and not to be skipped), undergoes intense computation, before its culmination into an order (buy and/or sell) that tries to materialise the opportunity envisioned by the trader. This is High-Frequency-Algorithm-Trading all about, where every microsecond gained matters. But, pure Erlang programs, especially when the processing is vertically partitioned (as oppose to horizontally, where we give entire application to a single “request” or single “client”, and spawn as many instances as the requests or clients), where (in vertical case) we hop from one process to next, the latency involved till the order is fired is totally unpredictable – that’s why the range is from 60 microsecond to several hundred microseconds.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I had even tried collocating entire computation (from receiving tick to firing order) into a single Erlang-process just to see how fast can it go; but, the metal performance of “C” is impossible (to even consider) to match (least to beat). But, programming and debugging in C/C++ is naturally expensive; safe-Rust at least takes many worries off the head. Erlang programming is still my preferred choice “for understanding” the data structures and control structures required for the application.<span class=DefaultFontHxMailStyle><span style='font-size:14.0pt'><o:p></o:p></span></span></p><p class=MsoNormal><span class=DefaultFontHxMailStyle><span style='font-size:14.0pt'><o:p> </o:p></span></span></p><p class=MsoNormal><span class=DefaultFontHxMailStyle><span style='font-size:14.0pt'><o:p> </o:p></span></span></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='border:none;padding:0cm'><b>From: </b><a href="mailto:jesper.louis.andersen@gmail.com">Jesper Louis Andersen</a><br><b>Sent: </b>09 April 2021 03:23 PM<br><b>To: </b><a href="mailto:trigunatit@gmail.com">Avinash Dhumane</a><br><b>Cc: </b><a href="mailto:max.lapshin@gmail.com">Max Lapshin</a>; <a href="mailto:lukasz@niemier.pl">Łukasz Niemier</a>; <a href="mailto:erlang-questions@erlang.org">Erlang Questions</a><br><b>Subject: </b>Re: gen_udp:recv()</p></div><p class=MsoNormal><span class=DefaultFontHxMailStyle><span style='font-size:14.0pt'><o:p> </o:p></span></span></p><div><div><div><p class=MsoNormal><span style='font-family:"Arial",sans-serif'>On Wed, Apr 7, 2021 at 3:50 PM Avinash Dhumane <<a href="mailto:trigunatit@gmail.com">trigunatit@gmail.com</a>> wrote:<o:p></o:p></span></p></div></div><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:4.8pt'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:4.8pt'><span class=gmail-m87837883364534983defaultfonthxmailstyle>I am taking the “tick-to-order” processing (in stock-market parlance) out of Erlang and into Rust to meet this ultra-low latency requirement.</span></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal><span style='font-family:"Arial",sans-serif'>I know Janes St. has a separate OCaml ingester which handles the message feed of this form and transforms it into a more digestible format for the rest of their systems. The key point is to demux the stream quickly and send relevant information into another CPU core for further processing. It also cuts down traffic in the case you can throw away a lot of messages from the feed you aren't interested in. At 10us per message, it isn't as if your general processing budget is very high. However, if you have a larger machine, the pure erlang solution is to use something like {active, N} or {active, true} and then move messages into other processes as fast as possible, as Valentin suggests. To me, 60-200us per udp message sounds way too high and my hunch is that this is due to configuration.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Arial",sans-serif'><o:p> </o:p></span></p></div></div></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span class=DefaultFontHxMailStyle><span style='font-size:14.0pt'><o:p> </o:p></span></span></p></div></body></html>