The Raspberry Pi as a Stratum-1 NTP Server (2012) | Hacker News Reader

The Raspberry Pi as a Stratum-1 NTP Server (2012)

satsignal.eu

68 pointswmanley34 comments

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.

Many companies use a cloud VM as their timeserver, I can't imagine it's worse than that.

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:

https://pastebin.com/f4N2NSQB

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’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.

I made one as well (with a Beaglebone) and also have notes:

https://github.com/jrockway/beaglebone-gps-clock

My guide is also quite out of date, but I did rebuild it from scratch a couple years ago by following my own instructions and they worked ;)

Some discussion on HN this morning: https://news.ycombinator.com/item?id=28141493

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.)

https://timemachinescorp.com/product/gps-time-server-tm1000a...

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.

I built one using the Adafruit GPS hat to get the PPS through a GPIO pin, no latency at all.

The Adafruit HAT was out of stock earlier this year so I ended up with a USB-to-serial for everything but PPS (using GPIO) setup.

It's not the prettiest but works brilliantly.

Now just waiting for Raspbian to respin to be Bullseye based so that I can update to a version of chrony with NTS support.

You can just build chrony yourself.

(And I think you can upgrade RpiOS to bullseye right now. It's not "officially" out but it seems to work anyway.)

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.

This (very old) guide covers how to build ntpd with ATOM kernel-mode polling of the serial pins. Does this not sidestep the issue?

Really cool project! Might want to add 2015 to the title, so people who have seen it before know it's the same one.

Is is possible to use leap second smearing with a setup like this?

The site has a guide for installing NTP on Windows servers that has saved me more than once. Under-rated source of information.

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.

Windows 10 has improvements for time accuracy but has strict requirements for achieving them.

See https://docs.microsoft.com/en-us/windows-server/networking/w...

That's a nice thing to build, but is having such an accurate clock source at home actually useful for anything?

Not specifically other than having a cool toy.

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.

https://github.com/hzeller/txtempus

I made one for my Citizen RF synced watch. It works.

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.

That's not my repo. To be clear. I followed this guys methodology, and can confirm it works. It's his work not my work.

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?

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.

So a nice middle ground is to buy a separate RTC and attach it via the I2C GPIO pins. The modules are ~$10 including shipping. I wrote up the software setup recently here: https://github.com/scottlamb/moonfire-nvr/wiki/System-setup#...

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.

https://engineering.fb.com/2021/08/11/open-source/time-appli...

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

I didn't even know that a "Miniaturized Atomic Clock" was a thing.

Looks like they cost a couple thousand dollars, but that's probably not a bad price for what you get.

https://www.sparkfun.com/products/14830

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.

anyone done something like this more recently?

some other discussion from a few years ago:

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

Reply on news.ycombinator.com