Wes makes a good point that’s worth highlighting. Most of the time a financial / HFT / low-latency system is doing….. nothing. It’s waiting to react. It’s when it wants to react that the timing constraints come into play (typically). In that sense it’s much like the brake circuit on a vehicle. It’s not active, until it is.

From: SG14 <sg14-bounces_at_[hidden]> On Behalf Of Wesley Maness via SG14
Sent: Monday, 03 October, 2022 15:18
To: sg14_at_[hidden]
Cc: Wesley Maness <wesley.maness_at_[hidden]>
Subject: Re: [SG14] Properties of HFT compared to other low-latency use cases

Timur,

I can comment some on the low latency space, but these are my observations and again it always depends and may differ from others work experience. I can't comment on HFT, that's a space I have not worked in.

Time scales: We care about nano and micro seconds. Usually nano (10s-100s) for market data flows and micro (100s to 1000 or so) for order and execution flow. Typically we measure these 1, 2 standard deviations. So you can say something to the effect of we can process this sell-side equity order request at 1micro 95 percent of the time.

Nature of the deadline and what happens if it's not met - that depends. But typically in this space you can measure and define something called alpha-decay or the rate at which you will lose your potential PnL as a function of time reacting to an event. So if you have a sharp alpha decay and you hit a fat tail outlier you can and potentially will take a hit on your PnL.

Topology - in our systems typically means a single thread pinned and with isolation. This thread is busy and events are purely market driven so not regular intervals. Externally driven.

Input/output - in our systems this is really just reading and writing into either shared memory or a memory mapped file. Typically using simple custom data structures using atomics where required. Many of the atomic usages are using specific memory ordering where appropriate.

Concurrency - atomics as mentioned above.

Hope that helps, next time I run into you, maybe Kona happy to dig deeper.

Thanks,
Wes

On Mon, Oct 3, 2022 at 11:24 AM Timur Doumler via SG14 <sg14_at_[hidden]<mailto:sg14_at_[hidden]>> wrote:
Hi SG14,

For a presentation this Thursday, I am currently comparing different use cases of low-latency programming, in particular video games, audio processing, and high frequency trading, and specifically the properties of the low-latency "hot path" for these use cases. I don't know much about HFT, so perhaps some experts here could answer a few questions? It would be immensely helpful.

- Typical time scales. In gaming, the deadline is typically one frame (~ 16 ms with 60 fps). In audio, it's typically the length of an audio buffer (~ 1–5 ms depending on the audio settings). Is it correct that HFT deals with much shorter timescales, i.e. you care about microseconds and even nanoseconds? What's the typical timescale?

- Nature of deadline. In audio and gaming, as long as you meet the deadline to generate one video frame/audio buffer, you're good, for example it typically doesn't matter if something takes 1.0 ms or 1.1 ms, as long as it *never* takes more than that. Is it correct that in HFT, it *does* matter? There's not so much a hard deadline, but more like the faster, the better, and reducing the operation by another microsecond is always desirable?

- What happens if deadline is not met. In audio, you get an audible glitch, which is very bad. In video games, you drop a frame, which is sometimes noticeable and not desirable. What about HFT? What's the typical cost of being too slow?

- "Topology" of the hot path. In audio, the "hot path" is a callback (controlled by the sound card + driver + OS kernel) coming in regular time intervals on a single dedicated audio processing thread. In video games, the "hot path" can be multiple threads, all dedicated to rendering. What about HFT? Is the hot path on a single thread? On multiple threads? Who calls this thread, how often, and under what circumstances? Is the hot path being called in regular intervals or following some kind of external event?

- What is the input and output of the hot path? In audio, the input is typically audio data or maybe MIDI data, and the output is more audio data. In video games, the input for the hot path the current state of the world, and the output is video frames. What is typically the input and output of the hot path in HFT?

- Concurrency. How does the hot path typically exchange data with other threads and the rest of the program? Atomics? Lock-free data structures? Something else?

I'd be very grateful for any insights you can give me!

Thanks,
Timur

P.S. I deliberately excluded embedded for now because it's such a diverse field that it's impossible to characterise as a whole: you have superloops, interrupt-driven flows, real-time operating systems and much more...
_______________________________________________
SG14 mailing list
SG14_at_[hidden]<mailto:SG14_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg14


--
Wesley C. Maness
347-387-7162

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.