So some time ago i migrated my pfSense from a PC Engines apu2 board to a VM on a Lenovo mini PC with it’s own dedicated network card.
Going through things trying to do a bit of a clean up i found the apu2 board again and thought why not make an NTP server out of this. I had already connected a Neo-6M module to the internal COM port in the past to use in pfSense. To spice things up i decided to use FreeBSD as the OS which i do not have much experience in for something different.
So far i have got as far as getting ntpd and gpsd running and talking to each other, bit of an offset on the GPS not sure what the deal is with that.
remote refid st t when poll reach delay offset jitter
==============================================================================
x127.127.46.0 .GPSD. 0 l 8 64 377 0.000 -121.71 2.537
*127.127.46.128 .PPS0. 0 l 6 16 377 0.000 -0.047 0.009
+119.18.32.223 110.142.180.39 2 u 37 64 377 2.107 -0.055 0.295
+119.18.32.153 203.35.83.242 2 u 55 64 377 14.741 -0.190 0.326
-180.150.2.31 202.6.131.118 2 u 46 64 373 10.803 +0.159 0.193
#119.18.32.1 203.35.83.242 2 u 51 64 377 25.403 -0.196 0.237
#202.142.143.61 202.6.131.118 2 u 36 64 377 44.068 +0.162 0.287
-67.219.100.202 110.142.180.39 2 u 36 64 377 2.181 +0.151 0.321
-159.196.3.239 192.168.0.138 2 u 53 64 377 30.589 -1.192 2.800
#139.99.236.38 123.50.147.14 2 u 30 64 377 14.646 +0.513 0.227
#220.158.215.21 126.11.196.147 2 u 33 64 377 15.490 +0.268 0.177
Thinking about next steps with this project and ideas, they would be.
Figure out why the gpsd GPS reference has a larger offset and what should be done about that.
Add an additional GPS module and connect to ntpd using the NEMA GPS driver.
Setup PTP server.
Happy to hear any feedback, ideas, or your own experiences setting up an NTP server.
How i have got to the point i am at (note this is not a guide or anything just notes about my setup process and configuration) see the spoiler below.
# Install packages
pkg install gpsd
# Add PPS to /boot/loader.conf
pps_load="YES"
dev.uart.3.pps_mode="0x12"
# Enable ntpd and gpsd in /etc/rc.conf
ntpd_enable="YES"
gpsd_enable="YES"
gpsd_devices="/dev/cuau3"
gpsd_flags="-n"
# Update ntpd configuration file /etc/ntp.conf
# GPS
server 127.127.46.0
# PPS
server 127.127.46.128 minpoll 4 maxpoll 4
fudge 127.127.46.128 refid PPS0
# Upstream NTP servers
server 0.au.pool.ntp.org iburst
server 1.au.pool.ntp.org iburst
server 2.au.pool.ntp.org iburst
server 3.au.pool.ntp.org iburst
# Edit /etc/devfs.conf to create device symlinks and set permissions on GPS serial port
link cuau3 gps0
perm cuau3 0664
# Enable COM3 and COM4 on apu2 board by adding to /boot/device.hints
hint.uart.2.at="isa"
hint.uart.2.port="0x3E8"
hint.uart.2.irq="4"
hint.uart.3.at="isa"
hint.uart.3.port="0x2E8"
hint.uart.3.irq="3"
Check out chrony as ntp client/server. Slightly different philosophy from ntpd.
Check support for hardware timestamps on your NICs (ethtool -T <NIC device>). Support can significantly improve precision when sync’ing time between machines
Configure your apu2 board as NTP server (enable server mode, setup security)
Make all your devices use your NTP server as opposed to connecting to their mothership (redirect DNS queries for time.windows.com, time.apple.com, etc to your NTP server; configure IoT and other devices to use your NTP server).
Enjoy a higher level of time precision and privacy.
That’s normal. The offset is the lag time between the point where your system registers a PPS pulse and the point your system registers the NMEA message.
So long the offset isn’t large enough to prevent PPS from locking onto the NMEA messages, there isn’t any cause for concern.
Since having a look over that i have disabled powerd on the system so that CPU clock scaling does not have an impact on time accuracy and enabled statistics so i can begin logging offsets for the GPS to then calculate the fudge for the IMT.
I have also adjusted my config so that the min and maxpoll for the GPS and PPS are 4 and upstream servers are 5. Apparently this should avoid items in the local ARP cache timing out and the system having to performing an ARP request each time a server is queried.
I think I’ve got a spare GPS radio around somewhere so for fun i’ll see how i can go about adding a second GPS radio to the system and connected to ntpd over the weekend.
There are tons of writeups on how to setup ntp+GPS, but all of them have the challenge that they’re at least 6 years old. The one you’re referencing is a good one as it explains the technical bits well.
However, it pretty much pre-dates systemd and as a result has the potential for people to mess up their OS as they follow steps to install it.
Nowadays, I find that the distributions (my experience is from a sample of 2) made it relatively easy to setup and configure ntp+GPS either using ntpd/ntpsec or chrony and gpsd. But you need to find out where the OS is “hiding” the conf files, the sockets, and how they start the daemons.
You’re right a lot of the guides you find are lacking in recency. The one I posted above is good in the way it describes the technical bits behind the setup but it still mentions using the shared memory driver.
Where as the Arch Wiki article talks about the newer and preferred GPSD-NG driver.
For better or worse most guides online are more or less copy, paste from each other and don’t nessecarily explain the configuration. Just do XYZ and it works.
Currently the GPS reciever I’m using is a u-blox NEO-6M which only receives GPS. Looking at options to get a GNSS reciever that can also receive GLONASS, BeiDou and Galileo. I did say I was building an overkill NTP server after all.
Hopefully at the end of all this I’ll have enough information to write up a rough how to that’s more up to date than most you see online.
I have a LEA-M8T timing board connected to my raspberry pi, but there really isn’t any appreciable precision difference from the regular ublox NEO-7m module apart from the timing mode support and ability to lock on to 3 constellations simultaneously (vs GPS only) on the M8T. Can’t speak for accuracy since I only have a single receiver running at any one time, nor do i really want to investigate that rabbit hole.
The newer 9th generation ublox modules will allow you to concurrently lock GPS+GLONASS+BEIDOU at the same time. Galileo can be enabled “for free” on both gen 8 and 9 modules if you have GPS enabled. Check ublox datasheet for more info.
The same board is half the price on taobao, so get it there if you know how to buy stuff from taobao.
The pin assignment on the M8T timing board is very similar to the RCB-F9T-0 board. VCC_ANT, VCC, both UART Tx and Rx pins, GND and time pulse 1 pins are the same.
So I’m still working on this the original SMB adapter I purchased never arrived and I had to wait ages before I could attempt to get a refund (thanks AliExpress). To be honest I’d set the project aside and kind of forgot about adding the second GPS.
A new one is in the way and I should hopefully have an update post after it arrives.