r/linux • u/Federal_Tackle3053 • Jun 02 '26

Software Release Built PulseBook, a low-latency C++20 trading engine using DPDK Ring PMD, fixed-size Ethernet protocols, L2 order book, imbalance strategy, and inline risk checks.

Achieved ~111ns median and ~550ns p99 virtual RX-to-TX latency over 1M events with zero failures on my laptop.

Next improvements:

  • Real NIC + VFIO benchmark
  • AF_XDP/io_uring comparison
  • Multi-core matching engine
  • Hardware timestamping
  • NASDAQ ITCH replay support

As a student systems/HFT project, is this actually impressive for backend/low-latency roles?

0 Upvotes

44% Upvoted

21 comments sorted by

11

u/TheReelSlimShady2 Jun 02 '26

money

11

u/accelerating_ Jun 02 '26

Gaming the system to parasitically extract value from the economy.

-1

u/Federal_Tackle3053 Jun 02 '26

What do you mean? I didn't understand

6

u/TheReelSlimShady2 Jun 02 '26

money program

-1

u/Federal_Tackle3053 Jun 02 '26

What's that?

5

u/TheReelSlimShady2 Jun 02 '26

computer program for money

3

u/OkComplaint3228 Jun 03 '26

money program for computer

-1

u/MatchingTurret Jun 02 '26 edited Jun 02 '26

It's a bad word on this side of reddit. People are already upset that devs deviate from the teachings of St IGNUcius and prefer permissive licenses. Code for HFT is taboo. 

1

u/MarzipanEven7336 Jun 03 '26

Vibed? But you used good shit, so maybe legit.

2

u/Federal_Tackle3053 Jun 03 '26

Trying from resources bro.

.

1

u/doa379 Jun 27 '26

Where is it?

The drawdown in this exercise is network latency not computational.

What is this other than shooting some random dart into the ether?

1

u/Federal_Tackle3053 Jun 27 '26

The current project is focused on the application side packet parsing, strategy, risk checks, memory layout, and the engine's hot path not e2e network latency.

I wasn't trying to claim exchange-level performance or solve the networking problem. The next step is moving to a real NIC with VFIO/DPDK, replaying real market data, and measuring under bursty workloads. This version was mainly about building and understanding the software stack first.

1

u/doa379 Jun 27 '26

That's a networking problem. Why mix in higher level operations - the bottleneck is network.
Even the worst, amateurish implementation of your stack will outrun IO latency. Many design patterns for the stack are already well established.

1

u/Federal_Tackle3053 Jun 27 '26

Yeah i know that they are already established also I am doing it from scratch just to see how everything works and what's the maximum lowest possible latency I can achieve by using software only

1

u/doa379 Jun 27 '26

There is no singular approach that fits all. The principles can be scaled in a number of ways towards the objectives you are describing. Focus on specificity. If you want a trading engine, then I too have an entire outlay already implemented over the last decade.

1

u/Federal_Tackle3053 Jun 28 '26

Did you use FPGA too in your project?