The operations a system is built out of — a cache reference, a memory read, an SSD read, a disk seek, a packet crossing a continent — span a hundred and fifty million to one. No linear picture holds that, which is why every version of this table is drawn on a ratio scale. What is worth carrying away is not the individual figures, which drift with the hardware, but the ratios between them, which decide designs and do not.
Core ideas
One quantity carries the lesson: how many memory references fit inside one disk seek. The scale and the bracket are the two things needed to state it in a form that survives.
A memory reference is about 100 ns and a disk seek about 10 000 000 ns, so the ratio is 100 000 exactly — a quotient of two integers, not a rounded decimal. That single figure decides more design arguments than any other number on this course: it is why an index is worth building, why a cache is worth having, and why “just read it from disk” and “just read it from memory” are not variations on one plan.
From 1 ns to 150 000 000 ns is a hundred and fifty million to one. Drawn linearly, every rung below the top decade lands on top of every other at the left edge, and the picture says only that the last one is large. On a logarithmic ruler a factor of ten is the same distance everywhere, so the gaps between rungs become readable — and the gaps are the content.
Every absolute figure here is a measurement on particular hardware and will be wrong within a few years; the ratios move far more slowly, and they are what a design decision actually turns on. So the durable form is the decade bracket: “a disk seek is between 10⁵ and 10⁶ memory references” is a sentence still worth saying when both figures have changed.
The material
Where the rungs come from, why the ruler is logarithmic, and what a linear intuition does to the ones near the bottom.
A reference latency is a measured figure for one elementary operation — a cache hit, a memory reference, a disk seek, a network round trip — quoted to one significant figure and used for estimating. It is data rather than a derived quantity: the lab prints every rung in full, and the only thing computed from them is the ratio between two.
Both ends of any ratio taken from that table are integers, so the ratio is exact. That matters more than it looks: a reader who is handed 99 999.99999 cannot tell it from a wrong answer, while 100 000 is obviously the number the lesson is about. The only rounded thing in the lab is where each bar is drawn, which goes through a logarithm and is a fact about pixels.
10 000 000 ns ÷ 100 ns = 100 000. A hundred thousand memory references fit inside one disk seek, and the ratio sits between 10⁵ and 10⁶. Said the other way round: if a memory reference took a second, a disk seek would take rather more than a day.
Because the alternative shows nothing. Drawn to a linear scale reaching 150 000 000 ns, the memory reference at 100 ns is less than one millionth of the width of the picture, and so is everything faster than it. Eleven of the fourteen rungs are crowded into the leftmost few percent of it. The picture would be honest about the largest number and silent about every comparison worth making.
A logarithmic ruler puts equal ratios at equal distances: the gap from 1 to 10 is the same as the gap from 10⁶ to 10⁷. That is the right scale for this table precisely because the questions asked of it are ratio questions — how many of these fit in one of those — and never difference questions.
That sentence is true of one comparison and badly wrong about the others, and which one a person has in mind is usually not stated. Reading a megabyte sequentially is 20 000 000 ns from disk and 1 000 000 ns from SSD, a ratio of 20: somewhat slower, fairly described. A disk seek against an SSD random read is 10 000 000 against 150 000, a ratio of 200/3. And a disk seek against a memory reference is 100 000. Same two words, three answers, three different decisions.
The pattern is that sequential work narrows the gaps and random work widens them, which is a preview of an argument “Storage Engines and Indexes” makes at length. Here the useful habit is smaller: before saying one thing is slower than another, name which operation on each, then take the ratio.
Two forms are worth keeping. The first is a handful of exact ratios: 100 000 memory references to a disk seek, 300 datacentre round trips to a cross-continent one, 20 sequential megabytes from SSD to one from disk. The second is the decade bracket for anything else — 10⁵ ≤ r < 10⁶ — which is what the lab prints beside every ratio and is the form that survives new hardware.
What these numbers are not is a model of a running system. They are single operations measured in isolation, with nothing queued behind them and nothing contending for the same device. A real disk seek under load takes longer than the figure above, and by how much is the subject of “Queues and Utilisation”. The ladder is a floor and a set of ratios, and it is honest about being only that.
Interactive
Pick two rungs; the ratio is the knowledge
Method
Name both operations, take the quotient, keep the bracket.
“Disk” is not an operation: a seek and a sequential megabyte differ by a factor of two on the same device and by far more against anything else. Almost every confused latency argument is two people comparing different operations and each assuming the other meant theirs.
The answer is “how many of the faster fit inside one of the slower”, which is the form the number gets used in. Both figures are integers, so keep the quotient exact rather than turning it into a decimal that has to be trusted.
10⁵ ≤ r < 10⁶ is the durable statement; the mantissa is not. A bracket stays true across a hardware generation and a three-digit ratio does not, and quoting the second suggests a precision the reference figures never had.
A factor of 100 000 says an index or a cache pays for itself many times over; a factor of 20 says the same choice is worth arguing about. The ratio is not the conclusion, but it is what tells you whether the conclusion needs thought or is already obvious.
The same two devices, three pairs of operations, and three ratios that do not support the same sentence.
The first two ratios share a decade bracket and the third is four brackets away. That is the whole reason to insist on naming the operation: the first two comparisons are arguments about cost and the third is not an argument at all.
300 datacentre round trips in one cross-continent round trip is the other figure worth keeping, because it is the one that makes geography a design input rather than a deployment detail. “Latency and the Tail” starts from exactly that number.
For a faded rehearsal, pick two rungs whose ratio you think you know — sending a kilobyte over a gigabit link against compressing a kilobyte, say — and write down your guess, the decade bracket you expect, and the design sentence you would base on it. Then select both in the lab. The exercise is worth doing on the pairs you are confident about.
You should be able to state the memory-to-disk-seek ratio and its bracket from memory, produce any other pair’s ratio off the ladder, say why the ruler has to be logarithmic, and explain what these figures leave out about a system under load.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.