Raspbery Pi is not really capable of being a serious time server out of the box (astronomical jitter) though it is fun to play with. I imagine that it would be possible to greatly improve it with some creative bare-metal or RTOS implementation, but in Linux the Pi is really just too unpredictable to do the job well. That is not to say that it's useless though; a Pi running Stratum 1 with GPS time is still going to be heaps better than anything you can get from a Stratum 2 server syncing over the public internet.
For serious DIY players, BeagleBone hardware has both hardware timestamping on ethernet and hard realtime IO capabilities through the PRU interface (used for PPS signal from your GPSDO). It makes a ridiculously superior (orders of magnitude) time server compared to Rpi.
Have you seen any projects/code that actually use the BBB PRU's to feed NTP? I have a Pi that can get pretty good stats (Chrony reports sub-microsecond) from GPS PPS with only one kernel flag change but I've always wanted to use the spare BBB I have laying around because it seems like it'd be superior. I've seen people talk about using the PRUs for it, but never actually seen anybody document how to do it and I don't have the time nor expertise to hack on it myself, at least not without some hand holding.
This guide is six years old which actually makes a difference here - the OS, gpsd, and ntpd, have all changed considerably and much of the software configuration instructions are now wrong.
The general concept still works fine but you will have to research more up-to-date documentation.
These are my notes from the last time I did it, which are pretty scratchy, but hopefully you can glean something useful from them:
I’d suggest using chronyd for anyone planning to set up a new time server this way. Unfortunately it’s not covered by guides as extensively as ntpd, but it’s less error prone in my experience.
I’ve had a buildroot image on a Pi 4 for over a year now, and it appears to be accurate to within 10 microseconds.
Recently built one myself (funny how that works with HackerNews). And would double down on your comments about gpsd and ntpd. My biggest problem was gpsd autobaud detection for the Ublox module I was using kept setting the wrong baud rate.
I followed this when implementing my own ~$100 stratum-1 NTP server. It's all over the place but if you spend enough time on it you can make your own guide. I know I made my own set of instructions after the third fresh install.
I never got SNMP/MRTG logging running correctly, but that's not a big deal to me for now.
I have been trying to make an accurate and precise raspberry pi desk clock. The key thing I need is PPS output. The older Uputronics modules drop the PPS signal when there isn't a 4-point lock. They also don't have an on-board RTC but the new ones do (grumble grumble).
I haven't been able to compile any repos that enable PTP emulation yet, but I haven't tried in the past year. The proper solution is probably to just buy another (newer) module with fewer quirks. The RTC alone would have saved me from an hour of headaches bootstrapping my home network.
On the other hand, if you just want a standalone, turnkey stratum 1 server, I've used a TM1000A for years. GPS, easy to set up, just sits there quietly and works. Not dirt cheap but not a lot more expensive, considering. (Not affiliated, just a satisfied customer.)
One thing I always wonder about with these small scale NTP projects is: they often reject getting 1PPS through a USB-to-serial converter, because USB is polled and just has too much jitter - then they'll choose a Raspberry Pi 1 and serve NTP over... a USB to ethernet converter. Or sometimes even USB-to-wifi!
One would think both interfaces would suffer the same problems, after all.
You’re not wrong, anything older than a Pi 4 is a bit flawed as an accurate time server. Even the Pi 4 needs a stable temperature or its clock speed will be unstable, as there’s no temperature adjusted clocksource, it just uses cpu.
On older Pi versions USB is run in kernel instead of on chip, causing thousands of cpu interrupts per second. Also its on board ethernet is run through USB.
I've got equipment racks that haven't been connected to a network in years. It's absolutely obnoxious when everything is a few minutes off from eachother. I just figured out how to set up one Windows box as an NTP server to keep everything else sane. The time doesn't have to be exactly right but it just needs to be consistent across everything. It's very confusing when a log file has a creation timestamp inside from one machine that is widely off from the Date Created timestamp on the network drive. We've got a nice rubidium source for the test equipment but I don't have any way to feed that to a Windows box.
In my case it was Active Directory having the time service fall into a bad state and propagating throughout the system. AWS instances don't have a proper clock and will fall out of sync by minutes within a day. Installing Meinberg's NTP works better than Windows Time out of the box.
I don't know who needs this kind of precision, especially on a Pi. But there's often a need to improve on the Pi's sucky out-of-the-box time experience. It doesn't have a battery-backed real-time clock. After a power outage, it will boot with time that's hours behind and then step the clock after the network becomes available.
Probably useful if you're in an area without reliable internet service, so you can have an accurate time source without internet. Most people probably don't require a high accuracy stratum-1 timesource for home, but for $100, why not?
However, I'm doing research into being able to turn this into a short range WWVB transmitter as I like radio clocks but my area does not get good reception. So I suppose, there's an ultimate end goal there.
LOL, I already have your repo starred previously. Awesome that you are on HN, I may reach out at some point whenever I actually find time to play with this.
I wonder how much of the world depends on GPS timesources for their time servers -- what would happen if GPS goes down?
Though I suppose that anyone that has strict time needs has multi-protocol GPS / GLONASS / Galileo / BeiDo receivers so it would take a huge disaster to knock out the time signal entirely.
Coincidentally, Facebook just released a solution to this problem:
To remove these dependencies, we’ve built a new dedicated piece of hardware called Time Appliance, which consists of a GNSS receiver and a miniaturized atomic clock (MAC). Users of time appliances can keep accurate time, even in the event of GNSS connectivity loss. While building our Time Appliance, we also invented a Time Card, a PCIe card that can turn any commodity server into a time appliance.
This post (and the FB post), and the associated comments started ye olde neurons firing, and I was wondering: how difficult would it be to set up 3 RPi/Beaglebone devices which are accurate to within 100ns of each other?
Agreeing with each other to within 100ns, should be possible when they're physically close to each other and share a PPS signal. Being accurate to within 100ns would be considerably more challenging I'd think.
That alone won't do, I'm afraid. 100ns is a tough target for Linux on a RPi. I'd think in addition to the PPS a 10MHz reference would be needed. I don't see how the Pi can count those in hardware (perhaps its worth to you to use one core for that in rt-linux?). The Beagle Bone {Black, Green, Blue ...} with its PRU is probably the more promising platform for such.
For serious DIY players, BeagleBone hardware has both hardware timestamping on ethernet and hard realtime IO capabilities through the PRU interface (used for PPS signal from your GPSDO). It makes a ridiculously superior (orders of magnitude) time server compared to Rpi.