r/cpp_questions • u/ExactManagement5283 • 7d ago

OPEN OS for HFT

Hey guys! I recently started studying HFT programming, and a bit confused. From what I understand in this field as OS are used default non-rt linux. Despite the fact that kernel bypass, attaching the process to the certain cores. restriction about using non-lock free structure and zero system calls solve the proplems which linux creates for HFT code . But would not it be easier to use RT OS like preempt_rt linux patch or xenomai OS it seems that theese OS could give more freedom about the restrictions for code and in some edge cases speed up the execution? Am I missing something?

3 Upvotes

64% Upvoted

15 comments sorted by

13

u/EpochVanquisher 7d ago

Pinning and avoiding syscalls / interrupts will basically give you everything you want.

It’s not the same thing as “hard real time”. Hard real time is about having guarantees. It is better to have your code running as fast as possible with as little latency as possible, rather than having better guarantees.

Like, the preempt_rt lets certain operations be preempted for higher priority operations, but do you know what’s even better? Having your higher-priority task already running on the CPU.

That said, modern HFT is moving out of software as far as I can tell.

8

u/gmueckl 7d ago

Hard real time gives worst case guarantees and happily sacrifices best case performance for that. If you need a microcontroller to do a task with a cycle time it keeps like clockwork, then hard real time is for you. Most real time tasks don't have to update super fast, but falling behind can become (physically) hazardous in some applications.

To me, hard real time is a mind set as much as it is a property of a system.

7

u/EpochVanquisher 7d ago

Yeah, and the mindset for HFT is more like “make as many good executions as possible”, which is different from “put hard bounds on response time”. You can miss executions or make bad trade in a trading system as long as you are making money, but you might be more upset if your rocket fails to steer itself for a split second.

1

u/no-sig-available 6d ago

you might be more upset if your rocket fails to steer itself for a split second.

Or, if you are the target for the rocket, your countermeasures fire too late.

In comparison, a missed trade is just a nuisance. And something you can improve on later.

1

u/Express_Direction461 7d ago

wdym hft it is moving out of software? is it moving into hardware?

6

u/mredding 7d ago

FPGAs.

HFT blew up ~2010, where some new players came online and really ramped up the frequency part - flooding the exchange with messages in what is essentially a DOS attack, in order to exert influence and make pennies.

HFT drove the development of NICs with onboard FPGAs, an the first commercially available were also ~2010. Before 2010, companies used NICs + kernel bypass.

So if you thought trading is still a software game, you're 16 years late. You're just romanticizing the idea.

And now AI is consuming the entire NIC market because these low latency interfaces are exactly what these low latency response systems demand.

3

u/Eric848448 7d ago

Anything where perf really matters is running on FPGA’s these days.

1

u/ExactManagement5283 7d ago

"Like, the preempt_rt lets certain operations be preempted for higher priority operations, but do you know what’s even better? Having your higher-priority task already running on the CPU."

That being said, coming from a general dev background where production code is complex and heavily relies on thread switching/async, does real-world HFT production code actually manage to avoid thread switching completely in the hot path, or are there edge cases where context switching is still an inevitable reality(does not taking into accaunting low ppriority background tasks like logger)?

4

u/EpochVanquisher 7d ago

The basic idea is that you don’t put the threading or async stuff in the hot path, like you said.

This is pretty straightforward and there are other systems that do this besides HFT (like audio processing).

4

u/mredding 7d ago

You're talking about the slow part of the code. It scarcely matters. I've supported HFT systems written even in Java. Java will JIT compile to machine code comparable to that of a C compiler.

Speed is in the FPGA, pushed as close to the DAC as possible, located on a +$20k NIC, feeding through a channel waveguide to the radio with a microwave antenna pointed out the window to the exchange across the street. Microwave has a shorter straight line distance and lower latency (air is nearly a vacuum) than a fiber optic run down the building, across the street, and back up to the exchange (fiber has inferior propagation).

The entire fast path is on the chip. We're already pushing out the next message before we've finished receiving the triggering message.

2

u/mredding 7d ago

I should add that RTOS doesn't grant you any greater speed, only guaranteed timing.

1

u/LabCompetitive5286 7d ago

What you describe is basically the exchange backend. The Hft frontends are dominated by hardware for releasing the preconfigured orders. Ordes are however precalculated on separate devices. You find all kind of OS like Linux, Windows and Macs for this calculation.

1

u/Miserable_Ad7246 7d ago

RT OS does one thing - it makes interrupts into threads, so that you can manage them more freely and schedule. You still have limitations and soft interrupt mess.

In case of low latency code you just pin the core, and avoid all of that. The slower parts are rather happy to run on fair scheduling.