Why can't these posts just say "microsecond" instead of the vague and misleading "ultra-low"?
Good point — ‘sub-microsecond’ is definitely more precise! Appreciate the feedback.
Ultra-Low-Latency Trading System
61–69 of 69 posts
Re: Ultra-Low-Latency Trading System
#62Those 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, a…
If that’s the case then 890ns is quite terrible. If for some reason you want to do this in software then the latency should be somewhere below 100ns.
Re: Ultra-Low-Latency Trading System
#63Earlier quoted context omitted.
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, a…
If that’s the case then 890ns is quite terrible. If for some reason you want to do this in software then the latency should be somewhere below 100ns.
That number is for a non-trivial software path (parsing, state updates, decision logic), not a minimal hot loop. Sub-100 ns in pure software usually means extremely constrained logic or offloading parts elsewhere. I agree there’s room to improve, and I’m working on reducing structural overheads, but this wasn’t meant to represent the absolute lower bound of what’s possible.
Re: Ultra-Low-Latency Trading System
#64Can 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.
Re: Ultra-Low-Latency Trading System
#65[deleted]
Re: Ultra-Low-Latency Trading System
#66Those 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.
It does not. If this was the case, round trip wire to wire latency below 1.0-1.2 microseconds in software would’ve been impossible. But it clearly is possible - see benchmarks by Solarflare, Exablaze, and others.
Re: Ultra-Low-Latency Trading System
#67CTO 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.
Re: Ultra-Low-Latency Trading System
#68Earlier quoted context omitted.
Just going over the PCI bus to the NIC costs you 500-600ns with a kernel bypass stack.
It does not. If this was the case, round trip wire to wire latency below 1.0-1.2 microseconds in software would’ve been impossible. But it clearly is possible - see benchmarks by Solarflare, Exablaze, and others.
You mean like this one directly from AMD showing a median 1/2 RTT ef_vi latency of 590ns (for UDP)?
Using their latency generation card that came out just a few months ago?
https://docs.amd.com/r/en-US/ug1586-onload-user/Latency-Test...
Re: Ultra-Low-Latency Trading System
#69Earlier quoted context omitted.
Yet more slop that amusingly tries to rebrand low pass filtering and dynamic feature selection as “strategic ignorance”
I understand — the reviewers clearly see it differently, which is why they’ve been carefully evaluating my paper for the past 15 days.
who are the reviewers? Statler and Waldorf?