GPS NTP server trial results
I made two NTP servers using Raspberry Pi single-board computers and GPS receivers.
The resulting NTP servers seem to work well.
Hardware
There are 5 computers in my evaluation.
- rpi5ntpeth4 - Raspberry Pi 5, 2025-05-06 Raspberry Pi OS, Waveshare NEO-M8T GNSS TIMING HAT
- rpi3ntpeth4 - Raspberry Pi 3, 2025-05-06 Raspberry Pi OS, MakerFocus GT-U7 GPS Module
- modest - Qotom fanless server, chronyd configured to use rpi5ntpeth4 as the sole NTP source.
- monarch - Dell PowerEdge R530,
up-to-date Arch Linux,
chronyd
configured withpool 2.arch.pool.ntp.org iburst
as a set of NTP servers - mirabilis - aging Dell Latitude E6420 laptop, Arch Linux last updated 2021-08-02,
ntp
4.2.8.p15-1, configured to use rpi3ntpeth4 as the single NTP source.
Raspberry Pi Servers
Both Raspberry Pi NTP servers are in a front office in my house, which has a bay window through which their antennas can see the sky. They’re both cabled to the same 8-port 1GbE TP-Link switch.
don’t think this is an issue because NTP (the protocol) doesn’t transmit lots and lots of info, only a few smallish packets once in a while. The same location for both servers has the benefit of virtually identical views of the sky and GPS/Glonass/Galileo satellites.
GPS Comparison
Below, two pieces of a screenshot taken with
cgps,
one instance running on each of the two Raspberry Pi servers.
I had both cgps
programs running in xterm
instances in the
same X11 server.
One screenshot captured both cgps
instances at almost exactly the same time.
Above: cgps
on Raspberry Pi 3, GT-U7 GPS module.
The “SB135”, “SB133” etc apparently stands for
Satellite Based Augmentation System.
I don’t know which SBAS cgps
references in the above image.
Above: cgps
on Raspberry Pi 5, NEO-M8T GPS module.
The top 2 satellites are the same as the RPi 3, but the Signal-to-Noise-Ratio (SNR)
is different, and not always higher.
No SBAS choices, either.
The NEO-M8T came with what looks like a better antenna.
The RPi’s are less than 2 feet apart, and the antennas are less than 5 feet apart. There must be something like a CPU or MPU in the modules making decisions about which satellites to use.
NTP timekeeping
rpi3ntpeth4
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#x NMEA 0 0 377 1 +130ms[ +130ms] +/- 1000us
#* PPS 0 3 377 11 +257ns[ +327ns] +/- 90ns
rpi5ntpeth4
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#x NMEA 0 0 377 1 +162ms[ +162ms] +/- 1000us
#* PPS 0 3 377 4 +792ns[ +860ns] +/- 237ns
modest
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* rpi5ntpeth4 1 9 377 225 +26us[ +62us] +/- 322us
monarch
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^+ 23.186.168.130 2 10 375 63 -4417us[-4417us] +/- 46ms
^+ 144.202.41.38.vultruserc> 3 10 377 499 +311us[ +311us] +/- 45ms
^* static.190.111.161.5.cli> 4 10 377 863 -154us[ -80us] +/- 27ms
^+ 23.157.160.168 2 10 375 245 +1338us[+1338us] +/- 54ms
mirabilis
remote refid st t when poll reach delay offset jitter
==============================================================================
*rpi3ntpeth4 .PPS. 1 u 63 1024 377 1.021 -0.069 0.041
Mirabilis runs ntpd 4.2.8p15@1.3728-o Wed Jul 1 17:02:17 UTC 2020 (1)
so the output above is not as clear as that of chronyc
.
It isn’t at all clear what the “delay”, “offset” and “jitter” units are.
Apparently “delay” is the round trip time from mirabilis to rpi3ntpeth4
and back in milliseconds.
I’ll accept that, ping rpi3ntpeth4
shows values from 0.862 ms, up to 1.02ms
An “offset” of 0.069 milliseconds would be 69 microseconds, which is similar to what modest exhibits with respect to the other Raspberry Pi NTP server.
Both of the Raspberry Pi servers have an estimated error relative to the GPS modules in the hundred nanosecond range. My Dell R530 has estimated errors in the tens of milliseconds from the pool NTP servers.
Compare clients
The idea is to have one client using each of the two RasPi/GPS module servers, and one client using ntp.org pool servers. Compare the 3 client machines against each other to see if one of them disagrees.
I used clockdiff to compare machines.
modest (client of rpi5ntpeth4)
host=monarch.glump rtt=0(0)ms/0ms delta=0ms/0ms Wed Jul 2 18:07:13 2025
host=mirabilis rtt=0(0)ms/0ms delta=0ms/0ms Wed Jul 2 18:07:28 2025
host=rpi3ntpeth4 rtt=0(0)ms/0ms delta=0ms/0ms Wed Jul 2 18:07:58 2025
monarch (client of 2.arch.pool.ntp.org)
host=modest rtt=0(0)ms/0ms delta=0ms/0ms Wed Jul 2 18:08:49 2025
host=mirabilis rtt=0(0)ms/0ms delta=0ms/0ms Wed Jul 2 18:08:58 2025
host=rpi5ntpeth4 rtt=0(0)ms/0ms delta=0ms/0ms Wed Jul 2 18:09:09 2025
host=rpi3ntpeth4 rtt=0(0)ms/0ms delta=0ms/0ms Wed Jul 2 18:09:21 2025
mirabilis (client of rpi3ntpeth4)
host=monarch rtt=0(0)ms/0ms delta=0ms/1ms Sat Jul 5 16:33:05 2025
I could only get this aged laptop’s clockdiff
(version clockdiff from iputils 20210202
) to show me the difference between it and monarch
.
Conclusion
Both of the GPS modules, a $12 GT-U7 and a $120 NEO-M8T,
work well as a home NTP server.
It appears that they keep the same time, at least to the nearest millisecond.
Further, they keep the same time as one of the ntp.org
pools of NTP servers.
It looks like clients of my Raspberry Pi + GPS module NTP servers
are within 1 or 2 milliseconds of the ntp.org
pool.
I spent too much money getting a Raspberry Pi 5 and the NEO-M8T module.
A Raspberry Pi 3 from my “spares box” and the GT-U7 module would work
just fine for a homelab Stratum 0 NTP server.