Vibe Engines
YouTube

Vibe Engines is free, interactive AI engineering & system design — runs in your browser. Pick a learning path

Latency Numbers Explorer

An interactive version of the classic "latency numbers every programmer should know." Compare the real time of an L1 cache reference, a memory read, an SSD read, a same-datacenter round trip and a cross-continent round trip — then scale them all to human time (where one CPU cycle is a second) to feel just how enormous the gaps really are.

  • L1 cache reference
    0.5 ns
  • Branch mispredict
    3 ns
  • L2 cache reference
    4 ns
  • Mutex lock / unlock
    17 ns
  • Main memory reference
    100 ns
  • Read 1 MB sequentially from memory
    3.0 µs
  • SSD random read
    16 µs
  • Read 1 MB from SSD
    49 µs
  • Round trip within same datacenter
    500 µs
  • Disk seek (HDD)
    3.0 ms
  • Read 1 MB from disk (HDD)
    5.0 ms
  • Round trip CA ↔ Netherlands
    150 ms

Order-of-magnitude figures — last reviewed 2026-07. Switch to human scale and a same-datacenter round trip becomes about a week, a cross-continent one years — the gaps that justify caching, locality and avoiding network hops.

Everyone agrees memory is fast and the network is slow, but the real gaps are far more extreme than intuition suggests. The twelve operations in this table span more than eight orders of magnitude, from half a nanosecond to 150 milliseconds. This explorer shows each one in real time, then stretches them all into human time so the distances become something you can feel.

What it computes

Each row is a fixed reference value in nanoseconds. Three things are derived from it:

real time   = ns shown in ns, µs, ms or s, whichever fits
human time  = ns read as seconds          1 ns → 1 s
bar width   = (log₁₀(ns) − log₁₀(0.5)) / (log₁₀(150,000,000) − log₁₀(0.5))
  • The human scale multiplies everything by one billion, so durations print as seconds, minutes, hours, days or years.
  • The bars are logarithmic: the fastest operation, an L1 hit, is an empty bar and the slowest, the cross-continent trip, is full. Each equal step along the bar is the same multiplication factor, about 10× per 12% of the width.

A worked example

Here is the whole table as the tool renders it:

OperationReal timeHuman scaleBar
L1 cache reference0.5 ns0.5 sec0%
Branch mispredict3 ns3.0 sec9%
L2 cache reference4 ns4.0 sec11%
Mutex lock / unlock17 ns17 sec18%
Main memory reference100 ns1.7 min27%
Read 1 MB sequentially from memory3.0 µs50.0 min45%
SSD random read16 µs4.4 hours53%
Read 1 MB from SSD49 µs13.6 hours59%
Round trip within same datacenter500 µs5.8 days71%
Disk seek (HDD)3.0 ms34.7 days80%
Read 1 MB from disk (HDD)5.0 ms57.9 days83%
Round trip CA ↔ Netherlands150 ms4.8 years100%

Read it as ratios. Main memory is 100 / 0.5 = 200× an L1 hit. A datacenter round trip is 500,000 / 100 = 5,000× a memory reference. Reading 1 MB from SSD is about 16× slower than from memory, and from a spinning disk about 100× slower than from SSD. The cross-continent trip is 300× a datacenter round trip.

Assumptions and limits

  • Representative, not measured. The values are fixed order-of-magnitude references, last reviewed in July 2026, not benchmarks of your machine.
  • Single operations. Real workloads overlap work: CPUs prefetch, SSDs serve many requests in parallel and networks pipeline, so throughput can be far better than one latency suggests.
  • Unloaded systems. Queues add delay. A disk or network link near saturation can be many times slower than its idle latency, and tail latency is worse still.
  • One geography. The long-haul figure is one route; other paths are shorter or longer.

How to use the result

  • Count the hops. A request that makes ten sequential same-datacenter calls spends about 5 ms on round trips alone, before any work.
  • Keep hot data close. Every level you avoid, network to memory or disk to memory, saves orders of magnitude, which is why caches pay for themselves.
  • Batch and parallelize remote calls. Ten calls in parallel cost one round trip, not ten.
  • Put users near servers. No code change removes 150 ms of distance; replicas and edge caches do.

How it works

  • Real times: L1/L2, memory, SSD, HDD, datacenter and cross-continent RTT.
  • One-click scale to human time, where 1 nanosecond becomes 1 second.
  • Log-scaled bars make the orders-of-magnitude gaps visible.
  • The intuition behind caching, locality and avoiding hops.

Frequently asked questions

What are "the latency numbers every programmer should know"?

A widely shared table of approximate timings for common operations, popularized by Jeff Dean and Peter Norvig and updated by others since. In the version used here, an L1 cache reference is 0.5 ns, main memory 100 ns, an SSD random read 16 µs, a round trip inside one datacenter 500 µs, a hard-disk seek 3 ms and a round trip from California to the Netherlands 150 ms. Knowing their relative scale is what lets engineers reason about where time actually goes.

Why scale them to human time?

Because nanoseconds and milliseconds both register as simply small, which hides the enormous gaps between them. The human-scale view stretches every figure so that 1 nanosecond becomes 1 second. Then a main memory reference takes 1.7 minutes, an SSD random read 4.4 hours, a same-datacenter round trip 5.8 days and a cross-continent round trip 4.8 years. Stretching the numbers into human time makes the difference between a cache hit and a network call obvious.

How should these numbers change how I design systems?

They explain why caching, locality and avoiding network hops matter so much. Each step down the hierarchy, from cache to memory to SSD to the local network to another region, is one to three orders of magnitude slower than the last. A design that turns a memory read into a same-datacenter call makes that operation about 5,000 times slower. The numbers are the intuition behind keeping hot data close and batching or avoiding remote calls.

Are these numbers exact?

No. They are order-of-magnitude figures, and real values shift with hardware generations: modern NVMe drives, memory systems and networks can beat or miss them depending on the machine and the load. The point is the relative scale, which has stayed remarkably stable. The gaps between cache, memory, storage and network are what matter, and those ratios hold far better than any single absolute number does, so measure your own hardware when precision matters.

Why is a cross-continent round trip so slow?

Mostly physics. Light in optical fiber travels at roughly two thirds of its speed in a vacuum, about 200 kilometers per millisecond, and a California to Netherlands round trip is at least 17,500 kilometers even along the great circle, which sets a floor of almost 90 milliseconds before any routing or processing. Real paths are longer than great circles, and routers add delay, which is how the classic figure reaches 150 ms. Caching and edge servers are the only real fix.