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]> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>

-- 
Wesley C. Maness
347-387-7162