Building a Nanosecond Clock Revealed a Hidden Time Bug

There's a particular kind of hubris that comes with building something precise enough to measure its own failure. Jeff Geerling discovered this when he assembled a Precision Time Protocol (PTP) clock that displays time down to the nanosecond—nine digits past the decimal point—only to realize his supposedly accurate time server was drifting by several seconds.

The irony isn't lost on him. "I built this PTP clock and now every time I look at it and my watch at the same time, I'm not quite sure what time it is," Geerling says at the opening of his build video. He's invoking what he calls "Seagull's law"—or possibly "Seal's law," he's not entirely sure—the idea that a person with one watch knows what time it is, but a person with two is never certain.

What makes this project interesting isn't just the technical achievement of building a nanosecond-precision display. It's that the clock became a diagnostic tool that immediately revealed problems in the infrastructure supporting it. When your timepiece is accurate enough, suddenly everything else looks unreliable.

Why PTP Matters Beyond the Lab

Precision Time Protocol sounds like something designed exclusively for physicists measuring neutrinos or financial traders trying to shave microseconds off transaction times. And yes, those are real use cases—Geerling mentions White Rabbit, an even more extreme timing standard used for "Earth-scale neutrino detectors."

But PTP has more mundane, relatable applications. At a St. Louis Blues hockey game Geerling attended, the entire stadium uses PTP to synchronize audio and video across hundreds of speakers and displays. When you're trying to keep a replay in sync across dozens of screens while the crowd is roaring, Network Time Protocol—the internet standard most of us rely on—isn't precise enough. NTP gets you within tens of milliseconds. PTP can get you within microseconds or better.

The difference? NTP works across the internet, tolerating variable latency and packet loss. PTP is designed for local area networks where you can control the infrastructure and implement hardware timestamping—capturing the exact moment packets arrive at the network card rather than when the operating system processes them. That distinction matters when you're measuring in billionths of a second.

The Build: Simpler Than You'd Think

Geerling's clock relies on a Raspberry Pi 4, two Waveshare LED matrix panels, an Adafruit RGB matrix HAT, and about $120-150 in total parts. The Pi 4 is particularly well-suited because it satisfies two requirements: easy GPIO interfacing for LED displays, and a network adapter that supports PTP hardware timestamping. The Pi 5, despite being newer, doesn't yet work with the RGB matrix library—a reminder that "better" hardware doesn't always mean better compatibility.

The hardware assembly involves minimal soldering—just three headers on the HAT. Geerling admits he's still figuring out how to properly clean flux residue from GPIO pins, one of those craft details that separates "works" from "looks professional." The software setup is more involved: disabling the Pi's audio to prevent GPIO conflicts, installing the RGB matrix library, compiling Oliver Etland's open-source PTP clock application, and wrapping it in a systemd service so it launches on boot.

Etland, who presented a similar clock at the 39th Chaos Communication Congress, open-sourced both the code and parts list after Geerling reached out. This is how niche technical projects propagate—someone builds something fascinating for themselves, presents it at a hacker conference, and suddenly makers worldwide are replicating it.

When Precision Reveals Problems

The clock worked. The display showed time in hours, minutes, seconds, and nine more digits of subsecond precision. But when Geerling compared it to his other clocks—including a GPS-synchronized reference that's accurate to within milliseconds—nothing matched. His PTP clock was drifting.

The culprit turned out to be his time server, which uses an Intel i226 network interface card. The Linux driver for this card has a bug in how it interprets the pulse-per-second signal from GPS. Most network cards trigger on the rising edge of the voltage pulse—when the signal goes from low to high. The Intel i226 driver, for reasons unknown, triggers on both the rising and falling edges.

This creates a 100-millisecond ambiguity window. "The problem that causes is sometimes it might be taking like the previous second of GPS data. Other times it might take the next second of GPS data and it confuses the clock," Geerling explains. Over time, this confusion accumulates into the multi-second drift he observed.

There's a patch available. Or Geerling could switch to a different time server using the Raspberry Pi's Broadcom network chip, which doesn't have this edge-triggering bug. Both solutions would work. But the fact that he had to discover this problem through building an absurdly precise clock raises questions about how many networks are drifting without anyone noticing.

The Rabbit Hole of Time

Geerling warns prospective builders: "This is a very deep rabbit hole and you can easily sink a few thousand hours, not to mention thousands of dollars into time." He's not exaggerating. His studio contains a rack of timing equipment—multiple clocks, GPS distribution systems, oscilloscopes for measuring pulse signals. This is what happens when you start caring about nanoseconds.

The technical challenges are genuinely interesting. PTP requires every network switch in the path to support the protocol. Your power supply needs to provide stable voltage or the display flickers. The 3D-printed bracket holding the two LED panels together needs precise measurements because the displays have 0.1mm of overhang that you don't want to stress.

But there's something deeper here about the nature of precision itself. Most of us live with "good enough" time—our phones sync occasionally, we're rarely more than a few seconds off. But entire industries depend on knowing the exact nanosecond. Financial markets require synchronized timestamps for trade execution. Telecommunications networks need precise timing for signal processing. Scientific instruments demand accuracy that makes GPS look coarse.

Geerling's clock sits in the uncomfortable middle ground: precise enough to reveal problems, not critical enough that those problems matter to anyone but him. It's a diagnostic tool that found a disease no one knew existed. Whether that disease needs treatment depends entirely on what you're trying to accomplish.

For now, Geerling has a beautiful display showing time that's probably wrong, powered by infrastructure he's still debugging, serving no practical purpose beyond his own satisfaction. Which might be the most honest thing you can build.

Marcus Chen-Ramirez is a senior technology correspondent for Buzzrag.