The Cost of a Microsecond: When Does Buying Speed Stop Paying for Itself?

A microsecond has a price, and the price of the next one is higher than the price of the last. The first microseconds come out of a trading system almost for free: a profiler run, a lock that did not need to be there, a copy that could be avoided. The last ones come out through custom silicon, private network routes, and a cabinet a few meters closer to the matching engine, each bought at a cost that would have looked absurd at the start. Every firm that competes on speed climbs this curve. The interesting question is not how far up it a firm can climb but where it should stop.

This piece sets out a simple way to answer that question. We treat latency as an input with a marginal value and a marginal cost. The value depends on the horizon of the strategy that uses the speed, and on nothing the firm's engineers control. The cost depends on which lever is being pulled and how far it has already been pulled. Where the two curves cross is the amount of speed worth buying. That crossing is different for every strategy, it moves whenever competitors invest, and for some races the right amount of speed to buy is none.

What a Microsecond Is Worth

Start with the value side. An opportunity in an electronic market decays from the moment it appears, as other participants act on it and prices adjust. The simplest description is exponential: a system whose latency from event to order arrival is L captures a fraction 2^(−L/h) of the opportunity, where h is the opportunity's half-life. The half-life is what distinguishes strategies from one another. For a price discrepancy between two venues it is tens of microseconds; for a reaction to a move in a related instrument it may be milliseconds; for a slower statistical signal, a good fraction of a second. A companion piece, Milliseconds Are Not a Strategy, uses the same model to ask whether speed matters at all. Here the question is narrower: what is one microsecond worth, in units that can be compared with what it costs?

The answer is the derivative. Removing one microsecond raises capture by (ln 2 / h) · 2^(−L/h), a fraction of the opportunity's full value. Figure 1 plots that quantity in basis points against current latency for three stylized horizons, on logarithmic axes. Each curve is a plateau followed by a cliff. The height of the plateau is ln 2 divided by the half-life, so a microsecond is worth a hundred times more to a strategy with a 20-microsecond half-life than to one with a 2-millisecond half-life, because it is a hundred times larger a share of the time available. The cliff arrives once latency exceeds the half-life. Past it, most of the opportunity is gone before the order leaves, and one microsecond more or less changes almost nothing.

Two consequences follow, and both are uncomfortable for anyone who thinks of speed as a continuous dial. The first is that the value of a microsecond is set by the strategy, not by the engineering. A firm whose inventory sits at second-scale horizons cannot make a microsecond worth more by being clever about it; the plateau for its strategies is a fraction of a basis point. The second is that for a firm slower than the half-life, small improvements are worth nothing. A system at one millisecond in a race with a 20-microsecond half-life gains nothing from removing ten microseconds; it has to remove nine hundred and eighty at once to reach the plateau. Investment in speed is therefore lumpy in a way budgets dislike: it pays only when it crosses the cliff, and a program that stops short of the cliff has spent money for no return.^[1]

What a Microsecond Costs

Now the cost side. Latency in a trading system lives in four places, and there is a lever for each. Software is time spent in code that did not need to run: copies, allocations, locks, system calls, and the movement of work between cores. Network is time spent on the wire and in the switches along it, which depends on the route, the medium, and the number of hops. Hardware is time spent in general-purpose processors doing work that could be done in a network card or a programmable logic device: parsing the feed, evaluating a rule, forming an order. Colocation is time spent covering the distance between the firm and the matching engine, the largest single component for anyone not already in the building and, once they are, a quantity fixed by the length of a cable.

Each lever has a capacity, the number of microseconds it can remove, and a cost curve that steepens as the capacity is used. Figure 2 stylizes this with one rule: the cost of the next microsecond from a lever is a base cost multiplied by exp(β · f), where f is the share of the lever's capacity already used and β measures how abruptly the lever runs out. The bars show each lever untouched, half used, and nine tenths used, indexed so that the first microsecond from software costs one. The parameters are illustrative. The shape is the argument.

The ordering at the start is the one most engineers would recognize. Software is cheap: a first pass with a profiler finds work that should not be on the critical path, and removing it costs a few weeks of a good engineer's time. Colocation is cheaper still per microsecond, because a single recurring fee removes thousands of them at once. Network and hardware are dearer from the outset, because they involve contracts, procurement, and scarce skills. The ordering at the end is different. Colocation runs out abruptly: once the firm is in the building, the remaining microseconds of proximity come down to which cabinet and how long the cross-connect, and they are barely for sale at any price. Software runs out more gently but runs out all the same; at some point the critical path contains nothing but the wire, the card, and the matching engine, and no profiler finds microseconds in code that is no longer on the path. Hardware is the lever with the most capacity left when the others are exhausted, which is why the participants at the front of the fastest races tend, in the end, to be as much hardware organizations as trading ones.

Where the Curves Cross

Put the two sides together and the amount of speed worth buying falls out. Figure 3 does this for a single stylized strategy with a half-life of 100 microseconds, starting from a system at 10 milliseconds. Speed is bought in halvings, each costing 1.4 times the one before, with the first priced at 0.4 percent of the opportunity's full annual value. Value captured rises with each halving as the system approaches the half-life; cumulative cost rises geometrically. The net benefit, value minus cost, is the curve that matters, and it has a single peak. Below the optimum the firm pays more for each microsecond than the microsecond returns; above it the firm leaves value on the table that would have been cheap to collect. The shallow dip below zero on the way down is the lumpiness of Figure 1 seen from the cost side: the firm is paying for halvings that have not yet brought it within reach of the opportunity.

The dashed curve shows what happens when the horizon shortens, as it does whenever competitors get faster in a race decided by relative speed. With the half-life at 30 microseconds rather than 100, the optimum moves left, to a latency that costs more to reach, and the net benefit at the optimum falls, in this parameterization by roughly a quarter. This is the latency arms race seen from inside one firm's budget. The firm must spend more to stand still, and what it earns for standing still is less than before. Nothing about its own engineering changed. The world moved, and the optimum moved with it.^[2]

The peak is also worth noticing for where it sits: well above the physical floor. A firm at the optimum in Figure 3 is not as fast as it could be; it is as fast as it is worth being, which is a different and less flattering number. A good deal of what looks from outside like engineering restraint is this calculation done honestly.

When the Race Is Not Worth Entering

The same model answers a question asked less often than it should be: whether to enter a race at all. Figure 4 repeats the optimization across a grid of half-lives and cost curves and reports, for each cell, the net benefit at the optimum as a share of the opportunity's full value. Rows are the strategy's half-life; columns are how steeply the cost of each successive halving grows. The top rows are the fast races and the right-hand columns the expensive ones.

Two regions stand out. In the lower left, where horizons are long and speed is cheap, nearly all of the opportunity is retained, because little speed is needed and what is needed costs little. In the upper right, where horizons are short and each halving is much dearer than the last, the best the firm can do is close to nothing: every latency it might reach costs more than the capture it would buy, and the optimum is to stay where it is and pursue something else. The boundary between those regions is where much of the industry's quiet strategic decision-making happens. Firms do not announce that they have declined to enter a race. They simply do not appear in it, and the model explains why they were right not to.

The Levers, Side by Side

Figure 5 summarizes the four levers in the terms this piece has used: what each removes, how much it typically removes, how its cost behaves, and where it stops paying. The entries are qualitative on purpose. The specific numbers differ by venue, asset class, and year, and any table that stated them would be wrong within a few quarters. The ordering and the shapes are more durable.

Our own practice follows from the model rather than from any attachment to speed for its own sake. We price latency per strategy, by asking what the half-life of its opportunities is and therefore what a microsecond is worth to it. We aggregate that value across the strategies that share a path, because a microsecond removed from a shared feed handler is bought once and collected by everything downstream of it.^[3] We buy speed in the order in which the levers are cheap, which usually means software first, colocation where the horizons justify it, and hardware only where the plateau in Figure 1 is high enough to pay for it. And we redo the calculation on a schedule, because the cliff moves.^[4]

None of this makes speed unimportant. It makes speed a purchase, with a price and a return, like any other input to a systematic process. Firms that treat it that way spend less than firms that treat it as a virtue, and they spend it in the right places. A microsecond is worth exactly what the strategy says it is worth, and no more.