2.9.1 Low-Latency from Zero

Basic Prerequisites: None beyond a willingness to think in nanoseconds. Helpful: Market Microstructure & Order Types.

---

1. Intuition & Practical Objective

This page builds the why of low-latency systems architecture with no systems-programming background required. The objective is one idea: a latency-sensitive strategy is a race, and the race is won or lost by the speed of the software path, so the software path is a first-class part of the strategy, not an implementation detail.

Start with the dumbest question: why would anyone spend millions to shave a microsecond off a computer program? Because in some strategies the microsecond is the profit. Here is the mechanism, in three steps.

1. Quotes go stale, and someone is always about to take them. Suppose you post a resting limit buy at $100.00 and new information arrives that makes the instrument worth $100.02. You want to cancel your stale order before anyone fills it at $100.00. A faster participant sees the new information, sends an aggressive order, and takes your stale quote - you have been adversely selected. The difference between cancelling first and being filled second is the whole game. (This is the micro-event view of Queue Position & Fill Probability.)

2. The winner is whoever’s bytes arrive first. It is not “who is smarter” on a given tick - it is who finishes the loop packet in → decide → packet out sooner. Two firms running identical logic differ only in the latency of that loop. The firm with the smaller number wins the race and the larger number pays it.

3. “Fast” is not one number. The loop is a sum of stages - the network card, the operating-system stack, your parser, your strategy, your serializer, your transmit. Optimizing “the program” is meaningless until you know which stage costs what. The entire discipline is: measure the budget, then delete work from it.

The one-sentence essence. “You cannot make light travel faster, and you cannot make the cache faster - so the only thing you control is how much work the machine must do per message, and the way to win is to do less work, more predictably, in the tail.”

---

2. Mathematical Ground Truth & Derivations

The additive budget. Model the path as a chain of stages. Total latency is the sum:

$$T_{\text{T2T}}=\sum _{i=1}^n{T}_i=T_{\text{wire}}+T_{\text{NIC}}+T_{\text{stack}}+T_{\text{parse}}+T_{\text{strategy}}+T_{\text{serialize}}+T_{\text{gateway}}+T_{\text{TX}}.$$

Two consequences follow immediately, and they organize the whole field.

(A) The mean is a sum; the extremes are a max. If you condition on the worst hop being slow - a context switch, a page fault, a cache miss on a cold structure - the total cost is set by the maximum single hiccup, not by the sum of hops. The relevant statistics are therefore percentiles, not averages. Define the tail ratio

$$R=\frac{Q_{0.99}}{Q_{0.50}},$$

where $Q_p$ is the $p$-th percentile of end-to-end latency. For a real trading path $R$ is comfortably above 2: the p99 (the number that decides close races) is not the median.

(B) A “fast” stage can still lose. A single-threaded handler is a queue. For an M/M/1-style server with arrival rate $\lambda$, mean service $\mathbb{E}[S]$, utilization $\rho =\lambda \mathbb{E}[S]$, the waiting time in queue is

$$W_q=\frac{\rho }{1-\rho }\mathbb{E}[S](\text{M/M/1}),$$

which diverges as $\rho \to 1$. A handler at 90 % utilization waits ten times longer than one at 50 % - even though its individual instructions are identical. Load, not just speed, sets latency. (General service-time jitter is handled by the Pollaczek–Khinchine formula on the hub.)

The physics floor. Light covers ~30 cm/ns in vacuum, ~20 cm/ns in fibre (≈5 ns per metre). No amount of engineering beats this; it is why the first latency decision is where the machine sits (colocation), not what code it runs.

---

3. Computational Implementation - the race, in numbers

Standard library only. We simulate the exact situation of step 1: two firms race to cancel a stale quote, with the only difference being the latency of their software path. We show that the distribution of latency, not its average, decides the win rate.

A 4x median difference becomes a ~99% win rate: the race is decided in the region where the two distributions barely overlap at all.

Now the inverse lesson - that a large median can still hide a competitive tail. Compare two architectures with the same median but different tail behaviour:

Two systems with the identical median have wildly different competitive behaviour. The tuned one is ~1.2x its median at p99; the naive one is ~6.5x. In a race against a disciplined competitor, the naive system loses exactly the ticks that matter - while its average latency looks perfectly fine. This is the single most important fact in the folder: low-latency engineering is tail engineering.

---

4. Failure Modes & First-Principles Breakdowns

1. “We’re fast on average” is the beginner’s trap. The average is a sum; the lose-the-race events are extremes. Every architecture decision below is judged by its effect on $Q_{0.99}$ and $Q_{0.999}$, not on the mean. (See 05 · Failure Modes.)
2. Latency is a budget, and the budget is physical. You cannot optimise your way past cache-miss and speed-of-light costs - you can only choose which costs you pay and how often. Confusing “optimize the code” with “remove the cost” wastes years.
3. Speed bought below the noise floor is wasted. If a competitor’s colocation advantage is 50 µs (physics), shaving 200 ns from your parser changes nothing about who wins. Measure the bottleneck stage before optimizing any stage - the naive instinct is to optimize the part you understand rather than the part that dominates.

---

5. References

• MacKenzie, Donald - Trading at the Speed of Light (2
• Biais, Foucault & Moinas - “Equilibrium fast trading,” JFE 116(2) (2
• Hasbrouck & Saar - “Low-latency trading,” J. Financial Markets 16(4) (2013). Empirical measurement of latency-sensitive order behaviour: short lifetimes, high cancel rates
• Harris, Larry - Trading and Exchanges (2

---

6. Connected Graph Bridges

• Back/adjacent: Market Microstructure & Order Types · Pillar 2 Hub
• Continue: 02 · The Latency Hierarchy · Index Hub
• Deeper: Queue Position & Fill Probability (the P&L of cancel speed)
• Cross-pillar: High-Performance C++ for Trading