DIY PTP Grandmaster Clock with a Raspberry Pi | Hacker News Reader

DIY PTP Grandmaster Clock with a Raspberry Pi

jeffgeerling.com

104 pointsingve33 comments

Just wanted to note: the entire configuration I'm building out is automated to run on any Debian/Ubuntu OS (not just a Pi), and my intent is to make NTP + PTP setup much more approachable for those who want to tinker with it.

The project is on GitHub: https://github.com/geerlingguy/time-pi

The blog post has more color/story around it, but the meat of it is over on GitHub, and right now I'm working my way through testing different network switches, installing an external GPS antenna, etc.

Also, if you're a PTP nerd, you might want to check out a project from the OCP-TAP, the Switchberry, an open hardware design for a PTP boundary/transparent clock with 7 ports! [1] This was built by the same PCB designers as the TimeHAT featured in my blog post, and I'm trying to hammer out some bugs in the bringup so they can be nice, lower-cost options for networks where you don't have the budget or need for enterprise-level PTP offerings, but still want a decent DIY setup.

[1] https://github.com/Time-Appliances-Project/Incubation-Projec...

Sorry if the article or references answered this but I couldn’t quite tell if so:

What are the bandwidth requirements of establishing clock sync around 1ms?

The bandwidth requirements are very low - you can sync time over a 56kbps serial port if you like.

However, the big benefit of PTP is having your precise timing and your main network connection share a single wire - so if your server needs 10 Gbps for whatever the server does, to get the highest accuracy you'd want a PTP compatible switch with 10Gbps ports.

The bandwidth is low, but the latency requirements are stringent since PTP does a wire delay calculation with multiple back-and-forth messages. If that gets affected by, for instance, jumbo frames being on, your bound on the clock value is much worse than if you have a relatively uncongested link.

If you're looking to setup a GPS-disciplined time-server at home, I highly recommend this writeup: https://austinsnerdythings.com/2025/02/14/revisiting-microse...

In the author's latest post he also sets up a pi as PTP grandmaster: https://austinsnerdythings.com/2025/02/18/nanosecond-accurat...

Austin from austinsnerdythings.com here - thanks for the shoutout! Four years later these posts continue to be some of the top posts people read on my blog.

Top hits from the past 30 days -

* 3441 hits - https://austinsnerdythings.com/2021/04/19/microsecond-accura...

* 2415 hits - https://austinsnerdythings.com/2021/09/01/how-to-deploy-vms-...

* 1990 hits - https://austinsnerdythings.com/2021/08/30/how-to-create-a-pr...

* 1870 hits - https://austinsnerdythings.com/2025/02/14/revisiting-microse...

so with the combined original post and the revisit post, easily the top topic

I wonder what kind of accuracy could be had with a cheapie USB GPS receiver. I wouldn't use that anywhere I had Internet connectivity, but in a disconnected location I wonder if it would get within a few ms of GPS time. I have an old USB GPS that shows up as a serial device (FTDI, or more likely a counterfeit) that I used back in my wardriving days, and later for moving map navigation on a laptop on road trips (as a dedicated navigator/passenger). It might be fun to dig it up and try it out.

Since I know Jeff frequents HN I'll go meta for a second and say that I noticed the Neatpatch cable management in the rack. I've been a fan of Neatpatch for a good long time. I don't use them in racks there there will be much churn, but they're mighty nice in locations that get wired once and only touched again when switches get replaced. It really makes a rack look-- erm-- nest.

I can +/-5ms jitter using a cheap GPS receiver with serial over USB.

Using the same receiver, but with a PPS wire to a GPIO pin on a raspberry pi, I get +/- 5µs jitter.

If you are interested, I have a write up with live graphs in the hamburger menu here: https://www.developerdan.com/ntp

People have taken various measurements, such as https://digitalnigel.com/wordpress/?p=3449 https://kloppenborg.net/blog/gps-pps-over-usb/ https://blog.dan.drown.org/pps-over-usb/

Of course, if you only need 'good enough' accuracy, a battery-backed RTC and NTP when you're online will generally be good enough.

> Since I know Jeff frequents HN I'll go meta for a second and say that I noticed the Neatpatch cable management in the rack.

I love Neat Patch units just to make it so when I'm popping things in and out of my racks, I can drop a few loops of slack into the box and not have it hanging out the back. As long as you keep it relatively organized, it's a tidy, if a bit expensive, solution.

For long-term use on a lab rack, I don't like the 1U Neat Patch though. It's too short for frequent use, I often get a little slice from the rigid plastic fingers. The taller 2U units have enough space to work inside—and larger punchouts on the back, for easier cable passthrough.

have a look at this write up:

https://austinsnerdythings.com/2021/04/19/microsecond-accura...

(not usb though -- uses pps)

Austin of austinsnerdythings.com here - that article does use PPS but there is a different writeup that does use USB that I refer to as my "millisecond accurate" guide - https://austinsnerdythings.com/2021/09/29/millisecond-accura...

Well done. Thanks for those.

I fully expect the results would make anyone with deep knowledge of PTP laugh at loud at how inaccurate/imprecise it is, but I still love for wifi to get a PTP.

There's so much audio and video stuff that works so much better with ptp. Even if it's vastly less good, its still gotta be some way to keep systems running on the same time, and that's a huge win. I'd love to see wifi PTP happen.

There's some really incredible research work a team did a while back, hacking their own PTP implementation stop a specific driver (adding timestamps to ath9k). https://github.com/zlab-pub/wifi-ptp

I'm guessing you're referring to: https://github.com/zlab-pub/wifi-ptp

But I remember reading somewhere (maybe it was in an OCP-TAP session, which they publish every month or so) that there was a serious effort to make hardware timestamping work in WiFi 7 or 6E, maybe? Can't find the reference.

That's been a big deal in industrial automation spaces. To have safety critical distributed applications, you need a way to say that a message is stale or something you can't respond to since the state of world might have changed since the data was acquired. As a result, there is a heavy need for some bound on time accuracy from wireless nodes, even if it's a bad bound (several ms instead of single digit us or similar), that still lets you do safety case decomposition.

This is one of the core pieces of tech in automotive for distributed safety cases, think sensors on different time scales with sync'd local clocks allowing for timestamping for staleness/aliveness.

This reminded me of one of my favorite links ever on HN.

https://dotat.at/@/2023-05-26-whence-time.html

At HN: Where does my computer get the time from? 851 points. Oct 5, 2023. 250 comments.

https://news.ycombinator.com/item?id=37778496

Supposedly NIST is being heavily affected by DOGE. Barbarians sacking the nation. :(

https://www.timebeat.app/

Also making some very nice stuff at great price points.

Are they great price points? Their open timecard starts at £2,999 or £5,495 with an atomic oscillator. Those prices are far outside the home hobbyist budget.

Interesting. I might have to get this PTP board, as I've never played with that. How much more precision do you get on the client side by eliminating the chronyd <-> network packet latency? There is still switching latency (I'm sure those things have buffers, because everything has a buffer these days) and the scheduling latency on the client side. Will I be able to notice this improvement with the right tools?

(In the past, I did this: https://github.com/jrockway/beaglebone-gps-clock, so I have a testbench for this sort of thing.)

Also, does anyone know if RTK helps much with timing? Every so often I connect up my clock to the NYS DOT RTK network (free!) and ... it works, but I don't know if it helps with anything.

> and the scheduling latency on the client side.

You might be surprised by how many PCs already have PTP capable NICs. I think it's standard on Intel's network chipsets. On Linux, just look for /dev/ptp0

However, PTP support is far from standard on network switches; and it doesn't work over wifi, or with USB-to-ethernet converters. So for sure plenty of clients can't use it.

> Will I be able to notice this improvement with the right tools?

If you're a precision timing aficionado? Possibly!

Just set up two devices with ethernet and GPIO pins, one that takes in a GPS 1PPS signal and acts as a PTP server, then a second that acts as a PTP client and outputs 1PPS.

Then connect your two 1PPS signals to the two inputs of an oscilloscope, trigger on one and watch how much the other is off by.

Make sure the PTP client is downloading big files, under heavy CPU load and suchlike, so you can see the effects of those.

Little bit controversial post - does not matter that much, few miliseconds either way, consistency is more important. just think what those clocks are used for inside of your hardware and you get your answer.

even "old" time signals like DCF77, WWV.... are sufficient enough for home lab. they can be heard even inside of a buildings, where GPS can have problems. And you can think about RTK signal as a signal in this more available signal category.

Most strange thing to me is that i have to set correct time in long wave radios (receiver), when they can just receive any of all those time signals.

PTP is mostly used for industrial control systems that need to have very precisely synchronized timing. The precision you can achieve depends a great deal on the clock hardware you're using. Network hardware, i.e. whether timing in network hardware is deterministic, also plays an important role. So the question is less "what can PTP do," it's more "what can my hardware do with PTP." Fundamentally PTP is just measuring network latency and applying that correction. But the quality of that measurement is critical, and there's nothing PTP can do to mask a crummy oscillator or a switch with non-deterministic timing.

In my little universe, PTP gets used for audio-over-IP systems like AES67, Dante, and AVB, which in turn get used for stage and studio (both very big and also quite small).

These systems are commonly used to trunk audio between points. Using them and a strand or two of glass or a cat6 cable is most of all that is needed to distribute dozens (or hundreds, and potentially thousands) of low-latency uncompressed audio signals.

PTP is part of how latency is kept low, and audio in-phase (which is a task that, itself, requires accuracy on the order of microseconds).

PTP is used in cellphone networks to coordinate radio timeslots between multiple base stations. They need at least microsecond accuracy.

From my industry PTP is used for video and audio sync down to single sample accuracy for audio.

See AES67/SMPTE ST 2110/IPMX.

You will be amazed how many things ptp ! Having ptp signals to test networks is a god send many errors are due to wrogn timing syncs ! Spirent loves ptp ! They partnered a lot with calnex !! We saw 80% data base write miss reduction in postgres once we started using ptp master clock across servers !

Also facebook did this https://engineering.fb.com/2021/08/11/open-source/time-appli...

As an aside, the TimeHAT V2 I used in the post was designed by some of the Meta timing lab team.

They've also designed Switchberry, a 7-port PTP boundary/transparent managed 1 Gbps switch which is run through a Raspberry Pi CM4. I'm currently testing it (along with some other switches).

The Switchberry is open hardware, too! https://github.com/Time-Appliances-Project/Incubation-Projec...

> And with tech like VR working its way into homes, precise time may become more important there, too.

How does VR relate to precise time? I assume we are talking about Virtual Reality and if that’s the case I don’t get the relation, or is there another VR abbreviation I’m ignorant to?

If you have more than one device you want to integrate into a VR space, having them within nanoseconds of each other means the lag/spatial difference will be much better. The closer and more stable in time, the better.

Currently most consumer VR gear is limited to a set of devices run through a single machine.

Reply on news.ycombinator.com