arrow_backBACK TO LOW-LATENCY TRADING SYSTEMS & ALGO TRADING — FROM THE ORDER BOOK TO A LIVE RETAIL ALGO
Lesson 07Low-Latency Trading Systems & Algo Trading — From the Order Book to a Live Retail Algo5 min read

Ultra-Low-Latency: FPGA & the Physics

October 28, 2026

TL;DR

When software is already maxed out, the biggest players buy speed in hardware and physics. The hardware ladder: plain software (microseconds-to-ms) → optimised C++ on CPU (the retail/prop sweet spot) → kernel bypass with a fast NIC like DPDK/Solarflare (skip the OS stack, sub-microsecond I/O) → FPGA cards (trading logic burned into hardware on the NIC, tens of NANOseconds, deterministic) → ASICs (custom silicon, the ultimate, inflexible, huge cost). Faster always means less flexible and more expensive. On the physical side they shorten distance: co-location with a metres-long cross-connect to the matching engine, and microwave/millimetre-wave links between venues (light is ~50% faster in air than glass, over a straighter path) that firms pay fortunes for. And they make it deterministic: CPU pinning, isolated cores, locked memory, busy-polling (no interrupts), and hardware PTP timestamps — chasing low JITTER, not just low average. This is a seven-figure arms race for a tiny edge; retail can't and needn't play it. Understand it; don't chase it. Educational, not financial advice.

This lesson is the one you asked for: a proper look at how the very fastest players get to almost zero latency. It’s genuinely fascinating engineering, and understanding it completes your mental model of the market. But I’ll bookend it with the same honesty as the rest of the course: this is a world to understand, not to chase. It’s a multi-million-dollar arms race for an edge measured in nanoseconds, and no retail trader can or should try to compete in it. Knowing it exists, and how it works, is what matters — so you can respect it and route around it.

The Hardware Speed Ladder

Once your software is as tight as it gets (Lesson 5), further speed comes from moving the logic closer to the wire — down a ladder of increasingly specialised hardware, each rung faster but less flexible and more expensive.

The hardware speed ladder: the closer the logic sits to the wire, the lower the latency. Plain software (Python): microseconds to ms, easy to write; flexible, slow. Optimised C++ on CPU: tuned, cache-aware, pinned cores; the retail/prop sweet spot. Kernel bypass plus fast NIC: DPDK/Solarflare skip the OS stack; sub-microsecond userspace I/O. FPGA card: logic in hardware, tick-to-trade on the NIC; tens of NANOseconds, deterministic. ASIC / custom silicon: burned-in logic, the ultimate; fastest, inflexible, huge cost. Faster equals less flexible plus more expensive. Big HFT firms put the hottest logic on FPGAs/ASICs; retail stops at tuned C++

The rungs, from accessible to exotic:

  • Plain software (e.g. Python). Microseconds-to-milliseconds, easy to write, flexible — and slow (Lesson 5). Fine for retail at slower horizons.
  • Optimised C++ on a CPU. Carefully tuned, cache-aware code on pinned cores. This is the sweet spot for prop desks and the fastest a realistic retail/prop setup reaches — serious speed without exotic hardware.
  • Kernel bypass + a fast NIC. Technologies like DPDK or Solarflare/Onload let your program talk to the network card directly, skipping most of the operating system’s network stack (stage 2 of Lesson 6’s budget). This gets userspace I/O into the sub-microsecond range. Pro territory, but still “just” software and a special card.
  • FPGA card. A Field-Programmable Gate Array is a chip you configure with hardware logic rather than software. Firms put the tick-to-trade path — parse the market-data packet, check the signal, emit an order — directly in the FPGA on the network card, so a decision happens in tens of nanoseconds, in silicon, without the CPU on the hot path at all. And crucially it’s deterministic — hardware doesn’t have GC pauses or OS scheduling jitter.
  • ASIC / custom silicon. The ultimate: logic burned permanently into a custom chip. Fastest possible, but inflexible (you can’t change it without fabricating new silicon) and astronomically expensive. Only the largest players go here.

The iron law of the ladder: faster = less flexible + more expensive. An FPGA is blisteringly fast but painful to develop for (you’re doing hardware design, not writing Python) and can’t be changed on a whim. That’s why even big firms keep only the hottest tiny slice of logic on FPGA/ASIC and the rest in software. Retail stops, sensibly, at tuned C++ (or even just decent Python for slow strategies).

Winning the Physics

Hardware speeds up the box; the other half of the race is the distance and the wire between boxes — pure physics, where the biggest money is spent.

How the big players win the physics: when software is already maxed, you buy distance, wire and silicon. Co-location: rent a rack INSIDE the exchange datacentre, cross-connect cable to the matching engine, metres not kilometres. The wire between venues: microwave / millimetre-wave beats fibre (light is about 50% faster in air, straighter path), firms pay fortunes for the lowest-latency route. On the box: FPGA tick-to-trade, kernel bypass, CPU pinning, NUMA-aware memory, busy-polling (no interrupts), hardware PTP timestamps. The ultra-low-latency playbook: shorten the distance (colocate, buy the fastest inter-venue link); skip every layer you can (kernel bypass removes the OS, an FPGA removes the CPU from the hot path, tens of nanoseconds); make it deterministic (pin cores, isolate CPUs, lock memory, busy-poll, hardware-timestamp PTP, the goal is low jitter not just low average). Honest caveat: a seven-figure arms race for a tiny edge; retail can't and needn't play it, compete on edge, costs and discipline, not nanoseconds

Three fronts:

  • Co-location (shorten the distance to the exchange). As in Lesson 6: a rack inside the exchange datacentre with a cross-connect of a few metres to the matching engine. This is the first and biggest physical win.
  • The wire between venues (shorten the distance across the market). When a firm needs to react in one city to something happening in another (arbitraging related instruments on different exchanges), the link between them matters enormously. Famously, firms pay fortunes for microwave and millimetre-wave networks between financial centres, because light travels ~50% faster through air than through glass fibre and can take a straighter, shorter path (towers in a line vs cable following roads and railways). Shaving a millisecond off a key route can be worth building a chain of microwave towers.
  • On the box (skip layers and remove jitter). Beyond the FPGA/kernel-bypass rungs above, the fine-grained tricks: CPU pinning (nail a thread to a core so it’s never moved), CPU isolation (keep the OS off that core entirely), NUMA-aware memory (keep data on the memory bank closest to the core using it), busy-polling (spin waiting for data instead of using interrupts, trading power for predictability), and hardware timestamping / PTP (Precision Time Protocol) to measure everything to the nanosecond.

The unifying goal is subtle and worth stating: the professionals chase low jitter, not just low average latency. Being fast on average but occasionally slow loses the race on exactly the trades that matter. Determinism — always being fast — is the real prize, which is why they strip out every source of unpredictability (the OS, GC, interrupts, memory distance) they can.

The Honest Caveat (Again)

Put it all together and the ultra-low-latency playbook is: shorten the distance (colocate, buy the fastest link), skip every layer you can (kernel bypass removes the OS; an FPGA removes the CPU), and make it deterministic (pin, isolate, lock, busy-poll, hardware-timestamp). It’s beautiful engineering.

It’s also a seven-figure arms race for a tiny per-trade edge, sustainable only at massive volume, and completely closed to retail. So the takeaway is the same as Lesson 6, now fully justified: know this world exists, understand how it works, and deliberately don’t play it. You compete on a real edge, lower costs, patience and discipline (Lesson 2), at horizons where nanoseconds are irrelevant. A retail trader who reads this lesson and thinks “I need an FPGA” has learned exactly the wrong thing; the right lesson is “I now understand why I should pick strategies where none of this matters.” That clarity is the gift of understanding the frontier.

Pitfalls to Avoid

  1. Thinking you need exotic hardware. FPGAs, kernel bypass and microwave links are for firms doing microsecond strategies at huge scale. Retail doesn’t need — or benefit from — any of it.
  2. Confusing “fast on average” with “fast”. The pros chase low jitter; an occasional stall loses the race. If you optimise, optimise for consistency too.
  3. Chasing the speed race instead of an edge. Every rupee and hour spent on latency you can’t win is taken from strategy, costs and risk — where retail money is actually made.
  4. Underestimating the development cost of fast hardware. FPGA/ASIC work is hardware engineering, slow and expensive — even firms keep only a tiny slice there.
  5. Ignoring determinism tricks when they’d actually help. If you ever do run latency-sensitive software, CPU pinning and avoiding GC (Lesson 5) are the accessible, high-value parts — not an FPGA.
  6. Treating this as a shopping list. It’s a map of a world to understand and route around, not a to-do list. Educational, not financial advice.

Quick Recap

  • The hardware ladder: software → tuned C++ (retail/prop sweet spot) → kernel bypass + fast NIC (sub-µs) → FPGA (tens of ns, deterministic) → ASIC (ultimate, inflexible). Faster = less flexible + pricier.
  • Physics wins: co-location (metres to the matching engine) and microwave/millimetre-wave links between venues (light is ~50% faster in air, straighter path).
  • Determinism tricks — CPU pinning, isolation, NUMA, busy-polling, hardware PTP timestamps — chase low jitter, not just low average.
  • It’s a seven-figure arms race for a tiny edge, closed to retail: understand it, don’t chase it. Compete on edge and discipline.
  • Educational, not financial advice.

Next lesson: back to what you’ll actually build — the full system architecture (React, Python, C++, Redis, PostgreSQL), order management, and the pre-trade risk checks and kill switch that keep you safe.