<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">On Wed, Apr 7, 2021 at 3:50 PM Avinash Dhumane <<a href="mailto:trigunatit@gmail.com">trigunatit@gmail.com</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-IN" style="overflow-wrap: break-word;"><div class="gmail-m_87837883364534983WordSection1"><p class="MsoNormal"> <br></p><p class="MsoNormal"><span class="gmail-m_87837883364534983DefaultFontHxMailStyle">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.<u></u><u></u></span></p><p class="MsoNormal"><span class="gmail-m_87837883364534983DefaultFontHxMailStyle"><u></u></span></p></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"></div><br></div></div></div>