2.8.6 Advanced Extensions

Basic Prerequisites: 05 · Failure Modes & Practice and 02 · The Tick-to-Trade Pipeline.

---

1. Intuition & Practical Objective

Once a firm has exhausted kernel bypass and FPGA, the next latency frontier is no longer in the box - it is in the medium, in the network fabric, and in the design toolchain. This page is the launchpad for the four extensions that matter:

1. Microwave & laser links - beating fiber by transmitting through air at $0.2997\text{m/ns}$ instead of glass at $0.2\text{m/ns}$, plus the shorter straight-line route.
2. In-network compute / programmable switches (P4) - doing aggregation inside the switch fabric so it never reaches a host.
3. HLS (high-level synthesis) - writing FPGA datapath logic in C++-like code instead of RTL, trading ~20% performance for ~4.7× productivity.
4. The exchange-side response (batch auctions) - the market-design answer to the arms race (Budish–Cramton–Shim), which would make much of this hardware obsolete by construction.

Each is one honest step past the single-box accelerator. Everything farther (photonic switching, cross-datacentre free-space optics, hardware-implemented market making) is linked from here.

Three “aha”s:

1. Medium beats code. Air is 1.5× faster than fiber; a straight microwave route is also shorter than routed fiber. Together they can save 40%+ of the propagation time on a metro or intercity leg - a gain no FPGA can match.
2. The network is a computer. If the switch can add, compare, and filter, then aggregation, risk limits, and even simple matching can live in fabric - removing an entire host round-trip.
3. Toolchains change the economics as much as silicon does. HLS turns an FPGA project from a 6-month RTL effort into a 6-week software effort, at a ~20% performance tax. That flip can move an FPGA from “unjustifiable” to “obvious.”

Why it matters. The physical layer, the fabric, and the toolchain are all first-order latency levers that most software-trained quants never consider. Knowing they exist - and their cost/benefit - is what separates a systems architect from an optimiser.

---

2. Mathematical Ground Truth & Derivations

2.1 Microwave vs fiber propagation

Propagation time over a route of length $d$:

$$T_{\text{prop}}=\frac{d}{c},c_{\text{fiber}}\approx 0.2\text{m/ns}=200\text{km/ms},c_{\text{air}}\approx 0.2997\text{m/ns}=299.7\text{km/ms}.$$

Air is $\times 1.5$ faster, and a line-of-sight path is also shorter than routed fiber (fibre cannot run straight; it follows rights-of-way and regeneration sites). The combined saving for crow-flies $d_{\text{air}}$ and fiber route $d_{\text{fiber}}$ is

$$\Delta T=\frac{d_{\text{fiber}}}{c_{\text{fiber}}}-\frac{d_{\text{air}}}{c_{\text{air}}}.$$

Microwave pays for this with line-of-sight hops, weather sensitivity, limited bandwidth, and tower/spectrum capex; the classic case is Chicago–NY, where micro/ millimetre-wave routes have historically beaten fiber by several milliseconds each way.

2.2 In-network aggregation

Aggregating one update from each of $k$ nodes:

$$T_{\text{host}}=k{t}_{\text{msg}}(\text{serialised into one host}),T_{\text{net}}=t_{\text{msg}}(\text{switch fans in all }k\text{inline}),$$

so the speedup is $k\times$ and - crucially - no host is in the loop, so no OS, no interrupt, and no per-message host cost is added. This is the principle behind programmable-switch aggregates (NVIDIA SHARP-style reductions, P4 match–action pipelines) and the risk of in-fabric risk limits.

2.3 HLS productivity

Productivity vs performance trade:

$${\text{lines}}_{\text{HLS}}\approx \frac{{\text{lines}}_{\text{RTL}}}{\rho },{\text{perf}}_{\text{HLS}}\approx (1-\pi ){\text{perf}}_{\text{RTL}},$$

with $\rho \approx 5$ (code reduction) and $\pi \approx 0.2$ (performance tax). The design-time improvement is what changes the ROI: if HLS cuts development from 6 months to 6 weeks, the same FPGA project clears a much lower alpha-capture bar.

2.4 The market-design escape hatch

Under a frequent batch auction (Budish–Cramton–Shim), orders within a short batch interval clear at a single uniform price, so a nanosecond of speed is worth nothing within the batch. The continuous-time arms race this folder documents is, in their framing, an artifact of a market microstructure choice - the deepest “failure mode” of all: the optimisations may be privately profitable and socially wasteful.

---

3. Computational Implementation - medium, fabric, and toolchain

Stdlib only. We compare microwave vs fiber on real routes, tabulate in-network aggregation, and price the HLS trade.

Three lessons in the numbers. (i) The medium saving is huge and consistent: 42.8% of one-way latency on Chicago–NY (2.996 ms saved) and London–Frankfurt (1.631 ms), because it combines a 1.5× faster medium with a shorter route - no amount of FPGA improves a millisecond-class leg. (ii) In-network aggregation is a pure $k\times$ win (256× at $k=256$) that also removes the host from the loop entirely. (iii) HLS cuts the design to 4.7× fewer lines for a 20% performance tax - and at an illustrative $36,000/day edge from a 3 ms advantage, the economics of the whole accelerator stack become visible in one number.

---

4. Failure Modes & First-Principles Breakdowns

1. Microwave is not free latency. Weather, fog, and rain attenuate millimetre-wave; hops add serialisation and re-transmission; bandwidth is limited by spectrum. The propagation gain is real but must be netted against availability and capacity - and the link is a single point of failure.
2. In-network compute puts logic where you cannot debug it. A P4 pipeline is even less debuggable than an FPGA: errors are silent, in fabric, and shared across traffic. Any in-switch limit must be shadowed and testable out-of-band.
3. HLS hides but does not remove hardware discipline. HLS code that ignores pipelining, II (initiation interval), and memory access patterns synthesises to garbage performance. HLS trades syntax difficulty for architecture difficulty; the architect’s job remains.
4. Physical-layer capex vs strategy decay. A microwave route is a multi-year capital commitment; alpha halves on a shorter timescale. Building for a latency edge that decays before payback is the physical-layer version of over-engineering.
5. Regulatory & market-design risk. Batch auctions, speed bumps, and access-fee regulation are all live threats to the economics of this entire stack. Budish–Cramton–Shim is not an academic curiosity; it is the scenario in which this folder’s optimisations are worth zero.
6. Correlation of the exotic fabric with the ordinary one. When several firms adopt the same microwave route or the same switch feature, the advantage compresses to zero and the arms race simply moves on - the S-curve saturates again, one layer down.

---

5. References

• Budish, Cramton & Shim (2015) - “The High-Frequency Trading Arms Race: Frequent Batch Auctions as a Market Design Response,” QJE 130(4), 1547–1621. The market-design critique; the case that the arms race is a microstructure artifact. ADV
• MacKenzie, Trading at the Speed of Light (2021)
• De Schryver (ed.) - FPGA Based Accelerators for Financial Applications (2015)
• MDPI Electronics (2024)
• DPDK and P4/programmable-switch documentation
• Aldridge, High-Frequency Trading (2nd ed.)

---

6. Connected Graph Bridges

• Back: 05 · Failure Modes & Practice · Index Hub
• Hardware tier: 03 · FPGA vs CPU vs GPU · 04 · Kernel Bypass & Networking
• Software/engineering: Low-Latency Systems Architecture · High-Performance C++ for Trading · FIX Protocol & Exchange Connectivity
• Market design & microstructure: Market Microstructure & Order Types · Limit Order Book Mechanics