{"id":210,"date":"2022-09-05T21:06:40","date_gmt":"2022-09-05T21:06:40","guid":{"rendered":"https:\/\/blog.lns.com\/?p=210"},"modified":"2022-09-05T21:23:33","modified_gmt":"2022-09-05T21:23:33","slug":"a-gps-stratum-1-ntp-server","status":"publish","type":"post","link":"https:\/\/blog.lns.com\/?p=210","title":{"rendered":"A GPS Stratum 1 NTP Server"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n
\n

“A man with a\u00a0<\/span>watch\u00a0knows what\u00a0<\/span>time\u00a0it is. A man with two watches is never sure.” – Segal’s Law<\/span><\/em><\/p>\n

Introduction<\/span><\/h1>\n

Keeping accurate time is critical for a number of things at an ISP. Accurate time is needed for debugging to see what devices were affected at what time.\u00a0 \u00a0If you had one reference clock that everything synced to, it really wouldn’t matter if it was 5mS off or 5 minutes off.\u00a0 So long as everything was based on that clock.\u00a0 Where it matters if you are trying to match your logs and data with devices that are not synced to your clock but to some other clock.\u00a0 So long as the other set of devices have synced to the same coordinated set of clocks you are, then you may have a good chance of lining up your logs to these other devices.<\/span><\/p>\n

In tracking an event you are looking for timestamps that are “newer” or “older”. The need for accurate\u00a0time may be in the milli or microseconds to see fast-moving events. In order to have a device to determine what time it is, it will normally use a protocol like the <\/span>Network Time Protocol (NTP).<\/span><\/a>\u00a0 NTP will send a packet out to another and trusted the NTP server to see what time it is. As there is latency on the Internet and in the protocol, NTP will also try to calculate the latency and adjust for it.\u00a0 <\/span><\/p>\n

Trusted NTP servers will be classified on how they get their\u00a0time such as based on an internal, highly accurate clock (<\/span>stratum 0<\/span><\/a>) or based on another NTP server (stratum 1, 2, etc.). For instance, a stratum 1 server will get its time from a stratum 0 server. A stratum 2 server will get its time from a stratum 1 server and so on.<\/span><\/p>\n

One does everything they can to minimize the workload on these servers so that when a server is queried, it can respond as quickly and reliably\u00a0as possible.\u00a0 So you may not have all of your devices connect to your only reference clock.\u00a0 You would distribute a second tier of NTP servers that would sync to your reference clock that your devices get their time from.\u00a0 As we are building a stratum 1 clock, you would deploy a set of NTP servers that would be stratum 2 servers for the rest of your devices.\u00a0 The stratum 2 servers would also sync with other NTP servers on the net to confirm that the reference clock is accurate.<\/span><\/p>\n

\n
\n

The NTP Server<\/span><\/h1>\n<\/div>\n<\/div>\n

This server uses the <\/span>Adafruit Global Positioning System (GPS) receiver<\/span><\/a> hat sitting on a Raspberry Pi 3 to get its time from GPS. GPS has to have a highly accurate time to have accurate\u00a0positioning reporting.\u00a0<\/span><\/p>\n

\n
\n

Setup<\/span><\/h2>\n<\/div>\n<\/div>\n

As mentioned above, our server will get its time from a stratum 0 server. In this case, a GPS clock is considered a stratum 0 server as it is a highly stable “coordinated clock”. Coordinated means that the time it calculates is coordinated with other clocks, such as the rest of the GPS satellite clocks as well as established clocks on the ground. Drift between these clocks is noted and adjusted as needed in order to keep all coordinated clocks in sync.<\/p>\n

GPS receivers indicated time a couple of ways. Every second, this string is sent to the Pi. The actual timestamp of what time it is is sent to the Raspberry Pi via a 9600 baud serial port. As the string can vary in length as well as various other delays such as the computer servicing serial port interrupts, this is not an accurate method of finding out what time it is. It can actually vary several hundred mS. An additional method needs to be conveyed to the Raspberry Pi indicating the actual moment when the second occurs. This is typically a General Purpose I\/O (GPIO) pin going high for a 100 mS and then going low. This GPIO pin is exposed to the computer as the Packet Per Second (PPS) interface such as \/dev\/pps0. The moment the GPIO pin goes high is the exact moment the second occurs. This is called the rising edge. So, timing software on the computer will get the time from the serial port and know the exact moment from the GPIO pin going high.<\/p>\n

On a computer, you will have one process looking at the data from the GPS and one process handing the NTP protocol. The second process will get the timestamp and could be configured to assume that the first process is looking at the \/dev\/pps0 interface or it could use the \/dev\/pps0 interface. In the current configuration, the NTP server (CHRONYd) is getting the GPS timestamp from the GPSd process via shared memory and the NTP server is looking at the \/dev\/pps0 interface for the exact moment that the second occurs.<\/p>\n

The GPSd daemon simply listens to the serial port and reports this via shared memory to the NTP server. We are using a compiled (source) GPSd as the packaged version was several revisions old for the Raspberry Pi distro. We are using an NTP server that is also a recent release and locally compiled called Chrony. In this case, Chrony is listening to the PPS interface to understand when the actual second starts.<\/p>\n

\n
\n

Debugging<\/span><\/h2>\n<\/div>\n<\/div>\n

You can check the status of the NTP server by running the Chrony command-line interface called “chronyc”.\u00a0 \u00a0A couple of commands are worth note are “sources” and “tracking”.\u00a0 The “sources” command will list the sources it is using for time.\u00a0 In the line below it shows PPS0 which is the Pulse Per Second GPIO pin.\u00a0 It is within the error rate tolerable of +\/- 8mS and is around 200nS. GPS0 is the GPS NEMA strings via shared memory from GPSd to CHRONYd. Normally this would be off around 500mS or so we compensate for that by putting an offset in the chrony config of 0.500 seconds. PSM0 and PST0 are GPS NEMA strings and PPS signals via shared memory. Since the GPS is not handling PPS, these entries will be zero. The rest of the various NTP servers that chrony can sync against and have some confidence that the GPS data is sane.<\/p>\n

chronyc> sources\r\n210 Number of sources = 8\r\nMS Name\/IP address \u00a0 \u00a0 \u00a0 \u00a0 Stratum Poll Reach LastRx Last sample\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0\r\n===============================================================================\r\n#* PPS0\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 0 \u00a0 4 \u00a0 377\u00a0 \u00a0 10 \u00a0 +227ns[ +516ns] +\/- 8186ns\r\n#? GPS0\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 0 \u00a0 3 \u00a0 377 \u00a0 \u00a0 5\u00a0 \u00a0 -12ms[\u00a0 -12ms] +\/-\u00a0 100ms\r\n#? PSM0\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 0 \u00a0 3 \u00a0 \u00a0 0 \u00a0 \u00a0 - \u00a0 \u00a0 +0ns[ \u00a0 +0ns] +\/-\u00a0 \u00a0 0ns\r\n#? PST0\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 0 \u00a0 3 \u00a0 \u00a0 0 \u00a0 \u00a0 - \u00a0 \u00a0 +0ns[ \u00a0 +0ns] +\/-\u00a0 \u00a0 0ns\r\n^- jane.qotw.net \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 2 \u00a0 4 \u00a0 377\u00a0 \u00a0 10\u00a0 \u00a0 +20us[\u00a0 +20us] +\/- \u00a0 88ms\r\n^- ntp18.kashra-server.com \u00a0 \u00a0 \u00a0 2 \u00a0 4 \u00a0 177\u00a0 \u00a0 10\u00a0 +1485us[+1485us] +\/- \u00a0 95ms\r\n^- time.iqnet.com\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 2 \u00a0 4 \u00a0 377 \u00a0 \u00a0 4\u00a0 -1098us[-1097us] +\/-\u00a0 141ms\r\n^- www.almaprovence.fr \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 3 \u00a0 4 \u00a0 377 \u00a0 \u00a0 5\u00a0 -1196us[-1196us] +\/-\u00a0 115ms\r\nchronyc><\/pre>\n
The Chrony tracking command gives you an update of stratum Chrony thinks it is. In this case Stratum 1, it has some confidence about slaving from the GPS receiver.<\/p>\n
chronyc> tracking\r\nReference ID\u00a0 \u00a0 : 50505330 (PPS0)\r\nStratum \u00a0 \u00a0 \u00a0 \u00a0 : 1\r\nRef time (UTC)\u00a0 : Fri Aug 21 22:01:59 2020\r\nSystem time \u00a0 \u00a0 : 0.000000248 seconds fast of NTP time\r\nLast offset \u00a0 \u00a0 : +0.000000319 seconds\r\nRMS offset\u00a0 \u00a0 \u00a0 : 0.000000776 seconds\r\nFrequency \u00a0 \u00a0 \u00a0 : 0.923 ppm slow\r\nResidual freq \u00a0 : +0.000 ppm\r\nSkew\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 : 0.034 ppm\r\nRoot delay\u00a0 \u00a0 \u00a0 : 0.000000001 seconds\r\nRoot dispersion : 0.000025404 seconds\r\nUpdate interval : 16.0 seconds\r\nLeap status \u00a0 \u00a0 : Normal\r\nchronyc><\/pre>\n
Configuration files<\/h2>\n
GPSd:<\/h3>\n
\/etc\/default\/gpsd<\/h5>\n
# \/etc\/default\/gpsd\r\n## mod_install_stratum_one\r\n# Default settings for the gpsd init script and the hotplug wrapper.\r\n# Start the gpsd daemon automatically at boot time\r\nSTART_DAEMON=\"true\"\r\n# Use USB hotplugging to add new USB devices automatically to the daemon\r\nUSBAUTO=\"true\"\r\n# Devices gpsd should collect to at boot time.\r\n# They need to be read\/writeable, either by user gpsd or the group dialout.\r\n# DEVICES=\"\/dev\/ttyAMA0 \/dev\/pps0\"\r\n# in case you have two pps devices connected\r\n# DEVICES=\"\/dev\/ttyAMA0 \/dev\/pps0 \/dev\/pps1\"\r\n# We tell GPSD to use the console serial port.  Alas, it will try to open \/etc\/pps0.  \r\n# Run Chrony first to grab the port so GPSd doesn't get it.\r\nDEVICES=\"\/dev\/ttyAMA0\"\r\n# Other options you want to pass to gpsd\r\nGPSD_OPTIONS=\"-n -r -b\"\r\nGPSD_SOCKET=\"\/var\/run\/gpsd.sock\"\r\nBAUDRATE=\"9600\"\r\n# Serial setup\r\n# For serial interfaces, options such as low_latency are recommended\r\n# Also, http:\/\/catb.org\/gpsd\/upstream-bugs.html#tiocmwait recommends\r\n# \u00a0 setting the baudrate with stty\r\n# Uncomment the following lines if using a serial device:\r\n\/bin\/stty -F ${DEVICE} raw ${BAUDRATE} cs8 clocal -cstopb\r\n# \/bin\/setserial ${DEVICE} low_latency<\/pre>\n
Chrony:<\/h3>\n
\/etc\/chrony\/stratum1\/10-refclocks-pps0.conf:<\/h5>\n
######################################################################\r\n# PPS0\r\n# PPS: \/dev\/pps0: Kernel-mode PPS ref-clock for the precise seconds\r\n# refclock\u00a0 PPS \/dev\/pps0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 refid PPS0\u00a0 precision 1e-7\u00a0 poll 3\u00a0 trust\u00a0 noselect\u00a0 lock PSM0\r\nrefclock PPS \/dev\/pps0 refid PPS0 trust\r\n# SHM(0), gpsd: NMEA data from shared memory provided by gpsd\r\n# refclock\u00a0 SHM 0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 refid GPS0\u00a0 precision 1e-1\u00a0 poll 3\u00a0 trust\u00a0 noselect\u00a0 offset 0.0\r\nrefclock\u00a0 SHM 0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 refid GPS0\u00a0 precision 1e-1\u00a0 poll 3\u00a0 trust\u00a0 noselect\u00a0 offset 0.500\r\n# SHM(1), gpsd: PPS0 data from shared memory provided by gpsd\r\nrefclock\u00a0 SHM 1 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 refid PSM0\u00a0 precision 1e-7\u00a0 poll 3\u00a0 trust\u00a0 prefer\r\n# SOCK, gpsd: PPS0 data from socket provided by gpsd\r\nrefclock\u00a0 SOCK \/var\/run\/chrony.pps0.sock\u00a0 refid PST0\u00a0 precision 1e-7\u00a0 poll 3\u00a0 trust\u00a0 noselect<\/pre>\n
\/etc\/chrony\/stratum1\/20-ntp-servers.conf:<\/h5>\n
# NTP Servers\r\npool  2.debian.pool.ntp.org  iburst  minpoll 4  maxpoll 4<\/pre>\n
\n
rc.local:<\/span><\/div>\n<\/div>\n
# for the GPS...\r\n# Start Chrony first to grab \/etc\/pps0 before GPSd does...\r\n\/usr\/local\/sbin\/chronyd\r\nsleep 2\r\nstty -F \/dev\/serial0 raw 9600 cs8 clocal -cstopb\r\n\/usr\/local\/sbin\/gpsd -n -b \/dev\/ttyAMA0 -F \/var\/run\/gpsd.sock<\/pre>\n
References<\/span><\/h2>\n