A Nanosecond Is 11.8 Inches Long

A nanosecond is 11.8 inches long. That is not a metaphor — it is a measurement, and Grace Hopper used to carry a bundle of them in her handbag.

Hopper, the computer scientist behind much of what became COBOL, spent a good part of her career explaining computers to people who did not build them. One question kept coming back: why does a satellite message take so long to arrive? The answer involved the speed of light, which is easy to state and almost impossible to feel. So she stopped explaining and started handing out props.

Each one was a piece of wire cut to 11.8 inches — roughly 30 centimetres. That is the farthest an electrical signal can travel in one billionth of a second. Hold it in your hand and the abstraction collapses: a nanosecond is not a duration, it is a distance. If a satellite sits 22,000 miles up, she would point out, you are asking a signal to cover an awful lot of those wires before anyone can answer you.

She scaled the demonstration up when she needed to. A microsecond, in her scheme, was a coil of wire 984 feet long. And when people asked her to justify a wasted second of compute time, she had a ready reply: a second is 186,000 miles of wire.

The number is smaller inside your circuit board

Light covers 29.98 cm in a vacuum in one nanosecond. Signals on a printed circuit board are slower. Propagation velocity in a typical FR-4 microstrip runs at around 60 to 70 percent of the speed of light, because the electromagnetic field is partly travelling through the board's dielectric rather than through air. In practice a signal covers something closer to 15 to 20 cm per nanosecond on a real trace, or a bit under 6 inches.

That correction matters more than the headline number, because it is the one you design against. A 6-inch trace costs you roughly a nanosecond. On a bus running at 100 MHz, one clock period is 10 nanoseconds and you will never notice. On a DDR interface or a gigabit link, a nanosecond is the entire timing budget.

Why length matching exists

Look at any densely routed board and you will find traces that meander in tight serpentine zigzags for no apparent reason. They are not decorative and they are not a routing mistake. They are the physical expression of Hopper's wire.

When a differential pair carries a signal, both halves have to arrive together. When a parallel bus carries sixteen bits, all sixteen have to land inside the same setup-and-hold window. The chips do not care how you achieve that — they care that the electrical distances are equal. So the router pads the short traces until every path is the same length, converting spare board area into matched delay. Length matching is arithmetic done with copper.

The same logic drives the rest of the discipline: keeping high-speed traces short, placing decoupling capacitors close to the pin they serve, putting a crystal next to its oscillator, giving a return current an unbroken ground plane to follow underneath. Every one of those rules is a statement about distance disguised as a layout guideline. Our PCB and hardware design work starts from exactly these constraints.

The debugging lesson

Here is the part that pays for itself. When an embedded system fails timing, the instinct is to blame the firmware. Engineers reread the interrupt handler, add delays, tweak the SPI clock divider, and rewrite a driver that was never wrong.

Hopper's ruler suggests looking elsewhere first. If a sensor bus is unreliable at 20 MHz but fine at 2 MHz, that is not a logic bug — that is a physics problem with a layout cause. Long unterminated traces, mismatched pair lengths, a ground plane split by a careless via fence, a pull-up too far from the line it holds up. The signal is doing exactly what it should. It simply cannot be in two places at once, and you asked it to be.

The habit worth building: before you open the debugger, look at the board and ask how far the signal has to go, and whether every path that must arrive together actually has the same distance to cover.

Where this bites in IoT work

Connected devices make the problem broader, because the wire keeps going after it leaves the board. A sensor node in a Philippine warehouse might sample a value in microseconds, buffer it in firmware, hand it to an ESP32 radio, cross a LoRa gateway, traverse a few thousand kilometres of fibre and land in a cloud broker. Every segment is Hopper's wire again, just longer.

That is why sensible IoT architectures decide early what has to be fast and what merely has to be eventual. A safety interlock cannot wait for a round trip to a data centre — it belongs in local firmware, close to the hardware, where the distances are inches. A daily telemetry rollup can happily take the long path. Confusing the two is how teams end up with a control loop that depends on Wi-Fi uptime.

Distance is a design input, not an afterthought. Hopper understood that in the 1960s, well before anyone was building connected sensors, and the wire in her handbag still measures the systems we build now.

If you are working through timing, layout or architecture questions on a connected product, talk to our engineering team — we work these problems from silicon to cloud.