Ultra-Low-Latency Trading System • Hacker News Board

Re: Ultra-Low-Latency Trading System

#11

Post by krish678 » Thu, Dec 25, 2025, 2:49 PM UTC

mgaunard wrote: post #5

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.

That’s a fair point, and I agree on wire-to-wire (SOF-in → SOF-out) hardware timestamps being the correct benchmark for HFT.

The current numbers are software-level TSC samples (full frame available → TX start) and were intended to isolate the software critical path, not to claim true market-to-market latency.

I’m actively working on mitigating the remaining sources of latency (ingress handling, batching boundaries, and NIC interaction), and feedback like this is genuinely helpful in prioritizing the next steps. Hardware timestamping is already on the roadmap so both internal and wire-level latencies can be reported side-by-side.

Appreciate you calling this out — guidance from people who’ve measured this properly is exactly what I’m looking for.

Re: Ultra-Low-Latency Trading System

#12

Post by dundarious » Thu, Dec 25, 2025, 2:50 PM UTC

mgaunard wrote: post #5

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.

Not really, often you can pre compute your model and just do some kind of interpolation on price change and get it done sub 1us wire-to-wire.

Re: Ultra-Low-Latency Trading System

#13

Post by krish678 » Thu, Dec 25, 2025, 2:50 PM UTC

andsoitis wrote: post #10

krish678 wrote: post #2

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 decis…

> 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 I think you need to frame the website better to position this project. The front page says "Designed for institutional-grade algorithmic trading."

That’s fair feedback — you’re right that the front-page wording overreaches given the current scope.

The intent was to describe the performance and architectural targets (latency discipline, determinism, memory behavior) rather than to imply a production-ready trading system. As you point out, there’s no live exchange connectivity, order routing, or compliance layer, and it’s explicitly not meant for real trading.

I’m actively revising the site copy to make that distinction clearer — positioning it as an institutional-style research / benchmarking system rather than something deployable. Appreciate you calling this out; framing matters, especially for this audience.

Re: Ultra-Low-Latency Trading System

#14

Post by nly » Thu, Dec 25, 2025, 2:50 PM UTC

mgaunard wrote: post #5

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.

Just going over the PCI bus to the NIC costs you 500-600ns with a kernel bypass stack.

Re: Ultra-Low-Latency Trading System

#15

Post by skinwill » Thu, Dec 25, 2025, 2:51 PM UTC

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?

Re: Ultra-Low-Latency Trading System

#16

Post by jgon » Thu, Dec 25, 2025, 2:51 PM UTC

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.

Re: Ultra-Low-Latency Trading System

#17

Post by delusional » Thu, Dec 25, 2025, 2:52 PM UTC

krish678 wrote: post #9

frunkad wrote: post #8

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

Fair point — agreed. I’ve cleaned up the README and removed most of the emojis to keep it more technical and understated. Thanks for the feedback.

Somehow this response makes it worse.

Re: Ultra-Low-Latency Trading System

#18

Post by ritvikos » Thu, Dec 25, 2025, 2:52 PM UTC

Proliferated with AI slop

Re: Ultra-Low-Latency Trading System

#19

Post by fruitworks » Thu, Dec 25, 2025, 2:53 PM UTC

seems like LLM

Re: Ultra-Low-Latency Trading System

#20

Post by [deleted] » Thu, Dec 25, 2025, 2:53 PM UTC

krish678 wrote: post #7

ramon156 wrote: post #6

Earlier quoted context omitted.

Forgive my ignorance but how can it be written in Rust and the not contain Rust due to "a rust file missing"

That’s a fair question — thanks for calling it out. The Rust component is a small, standalone module (used for the latency-critical fast path) that was referenced in the write-up but was not included in the last public commit due to an oversight. Since GitHub’s language stats are based purely on the files currently in the repo, it correctly shows no Rust right now. I’m updating the repository to include that Rust mod…

[deleted]