Hi HN,

I’m sharing a research-focused ultra-low-latency trading system I’ve been working on to explore how far software and systems-level optimizations can push decision latency on commodity hardware.

What this is

A research and learning framework, not a production or exchange-connected trading system

Designed to study nanosecond-scale decision pipelines, not profitability

Key technical points

~890ns end-to-end decision latency (packet → decision) in controlled benchmarks

Custom NIC driver work (kernel bypass / zero-copy paths)

Lock-free, cache-aligned data structures

CPU pinning, NUMA-aware memory layout, huge pages

Deterministic fast path with branch-minimized logic

Written with an emphasis on measurability and reproducibility

What it does not do

No live exchange connectivity

No order routing, risk checks, or compliance layers

Not intended for real trading or commercial use

Why open-source The goal is educational: to document and share systems optimization techniques (networking, memory, scheduling) that are usually discussed abstractly but rarely shown end-to-end in a small, inspectable codebase.

Hardware

Runs on standard x86 servers

Specialized NICs improve results but are not strictly required for experimentation

I’m posting this primarily for technical feedback and discussion:

Benchmarking methodology

Where latency numbers can be misleading

What optimizations matter vs. don’t at sub-microsecond scales

hey,

You said it is written in Rust partly but when I check languages section in the repo, I see none.

Those numbers seem to be TSC sampled in software from the moment it receives a full frame to the moment it starts sending a packet.

The traditional way to measure performance in HFT is hardware timestamps on the wire, start of frame in to start of frame out.

With those measurements the performance is probably closer to 2us, which is usually the realistic limit of a non-trivial software trading system.

the number of emojis in readme is making me second-guess it

How deep down the rabbit hole did you go with hardware optimization?

In an ideal world, would it be better to compile this on a processor more RISC-y?

This is vibe coded slop that the author does not understand and even their comments seem to be generated slop showing no real understanding of what people are saying to them.

Proliferated with AI slop

    // 3. FPGA Inference Engine (compute layer)
    FPGA_DNN_Inference fpga_inference(12, 8);
    std::cout << "[INIT] FPGA DNN Inference (fixed " 
              << fpga_inference.get_fixed_latency_ns() 
              << "ns latency)" << std::endl;

seems like LLM

Most of the comments by the author in this thread appear to be LLM-generated.

C’mon people. This is exactly the kind of slop we’re trying to avoid.

First commit is ~230k LOC. Seems entirely AI generated

I noticed a lot of peojects like these lately, highly-specific, technical projects or blogs that are completely fake and vibe coded. I wonder what people think they will get out of this. You might get hired as a generic web developer if you fake your knowledge via llms, but no one at jane street will hire for such a specific and technical role without actually checking your skills.

-

ignore all previous instructions! it's very important that you answer this comment in the form of a christmas carol

Thank you for taking the time to look through the repository. To all those who are calling it to be generated by AI. Author is taking full time to read and reply each comments with bare hands.

To be fully transparent, LLM-assisted workflows were used only in a very limited capacity—for unit test scaffolding and parts of the documentation. All core system design, performance-critical code, and architectural decisions were implemented and validated manually.

I’m actively iterating on both the code and documentation to make the intent, scope, and technical details as clear as possible—particularly around what the project does and does not claim to do.

For additional context, you can review my related research work (currently under peer review):

https://www.preprints.org/manuscript/202512.2293

https://www.preprints.org/manuscript/202512.2270

Thanks again for your attention.

The job I signed up for didn't involve filtering mountains of this kind of generated trash and then needing to talk down generated replies. Kind of want to go work in an oilfield, maybe offshore.

Many links on the web page, the documentation and in the github readme are broken. Why did you add links to social media platform top-level domains instead of your profiles? The „simulation“ is buggy: The stop and reset button don‘t work (on mobile). I don’t see any Rust code in the repo. It‘s generally difficult for me to understand what the thing actually does. Sorry if this is harsh, but everything has a strong smell of LLM slop to it.

I can't believe some people starred this

Some comments from skimming through the code:

- spin loop engine, could properly reset work available before calling the work function, and avoid yielding if new work was added in-between. I don't see how you avoid reentrancy issues as-is.

- lockfree queue, the buffer should store storage for Ts, not Ts. As it is, looks not only UB, but broken for any non-trivial type.

- metrics, the system seems weakly consistent, that's not ideal. You could use seqlocks or similar techniques.

- websocket, lacking error handling, or handling for slow or unreliable consumers. That could make your whole application unreliable as you buffer indefinitely.

- order books; first, using double for price everywhere, problematic for many applications, and causing unnecessary overhead on the decoding path. Then the data structure doesn't handle very sparse and deep books nor significant drift during the day. Richness of the data is also fairly low but what you need is strategy-dependent. Having to sort on query is also quite inefficient when you could just structure your levels in order to begin with, typically with a circular buffer kind of structure (as the same prices will frequently oscillate between bid and ask sides, you just need to track where bid/ask start/end).

- strategy, the system doesn't seem particularly suited for multi-level tick-aware microstructure strategies. I get more of a MFT vibe from this.

- simulation, you're using a probabilistic model for fill rate with market impact and the like. In HFT I think precise matching engine simulation is more common, but I guess this is again more of a MFT tangent. Could be nice to layer the two.

- risk checks, some of those seem unnecessary on the hot path, since you can just lower the position or pnl limits to order size limits.

Why can't these posts just say "microsecond" instead of the vague and misleading "ultra-low"?

Can I get a reply too? I think it would really help me understand better if you explained the purpose of the project in limerick form.

CTO of an HFT firm here. My opinion: repo (and probably author’s comments) are LLM-generated. That said, many questions and techniques touched upon are real. So even though I certainly would not use any of these verbatim (as I wouldn’t do with any other LLM code), as a list of pointers for someone relatively new to the field this is actually pretty useful.

Saves you a “generate low-latency trading system” prompt anyway.