Trading & Capital Markets · Chapter 8 of 8
Latency: where it comes from, and what it costs to remove
A budget in microseconds, an arms race with a physical floor, and the honest question of whether you should be in the race at all.
Latency is the most romanticised subject in trading and one of the most misunderstood. It matters enormously for a small number of strategies and is close to irrelevant for most others. Being able to say which is which is more valuable than knowing the numbers.
Why time matters at all
Because of price-time priority. At a given price, the queue is ordered by arrival. Being faster does not get you a better price — it gets you ahead of everyone else who wants the same price. Two consequences follow that people frequently miss:
- Latency matters most for strategies that compete for the same fill. Market making, arbitrage between correlated instruments, and reacting to a public event. If your edge is that you know something others do not for the next three days, microseconds are irrelevant.
- It is relative, not absolute. Being 5 microseconds slower than the fastest participant in a race you are competing in is fatal; being 50 milliseconds slower than them in a strategy where you are not competing costs you nothing.
- Queue position is the actual currency. A market maker cares about being early in the queue at a price level, because the queue is served in order and the last person in it gets filled precisely when the price is about to move against them.
Where the microseconds actually are
The distribution surprises people. The strategy logic — the part everyone assumes is the bottleneck — is usually a few hundred nanoseconds. The time is elsewhere:
- Wire to application. The kernel network stack costs several microseconds and a context switch. Kernel bypass — Solarflare Onload, DPDK — removes most of it by mapping the NIC directly into the application's address space.
- Parsing. Decoding the exchange's binary protocol. Often the largest software component, which is why it is the first thing moved to an FPGA.
- Encoding and sending. The same in reverse.
- Jitter, which matters more than the mean. A garbage collection pause, a page fault, a CPU frequency change, a thread migrating across NUMA nodes, an interrupt. These produce a long tail, and the tail happens exactly when the market is busiest — which is when it costs you. Anyone who quotes a mean latency without a p99.9 has not measured properly.
The physical layer, where the money really goes
- Colocation. Your servers in the exchange's own data centre. NSE and BSE both offer it in India; in the US the relevant halls are the exchange data centres in New Jersey and the CME's in Chicago. Exchanges equalise cable lengths within the hall precisely so that rack position confers no advantage — a regulatory-driven fairness measure.
- Cross-connects. The physical cable from your rack to the exchange's access switch. Priced monthly, and the count adds up.
- Direct feeds versus consolidated. In the US, taking each exchange's own feed and building your own view is faster than the consolidated tape. This is a data cost, not an engineering one, and it is the largest single latency decision most firms make.
- Inter-city links. The Chicago to New Jersey route is the famous one. Straight-line fibre beat the railway-following route; microwave beat fibre because radio through air travels close to the speed of light while light in glass travels at about two-thirds of it. Microwave carries far less capacity and degrades in heavy rain, so firms run both and fail over. Hollow-core fibre is the more recent development, closing part of the gap without the weather problem.
The honest question, and the one that reads as senior
Every latency conversation should include: is this a race we can win, and is winning it worth what it costs?
The arms race has a physical floor. Once you are colocated, on direct feeds, with kernel bypass and FPGA parsing, the remaining differences are small and the cost of each further microsecond rises steeply. A firm entering late is buying into the expensive end of a curve against incumbents who bought the cheap end years ago.
The strategically interesting answer is frequently to compete somewhere else — on a signal with a longer horizon, in a less contested instrument, or on execution quality rather than speed. Being willing to say that in an interview at a firm that does race is not a weakness; it demonstrates that you understand what the spend buys.
Measuring it properly
- Hardware timestamps at the NIC, in and out. Software timestamps are the same order of magnitude as the thing being measured.
- PTP for clock synchronisation, not NTP. NTP is accurate to milliseconds; you need sub-microsecond, and unsynchronised clocks make cross-machine measurements meaningless.
- Histograms, always. Report p50, p99, p99.9 and max. A mean hides exactly the behaviour that costs money.
- Measure in production, continuously. Latency regresses silently as code and configuration change, and a benchmark run once is a number about the past.
Check yourself