remote refid st t when poll reach delay offset jitter =============================================================================== *SHM(1) .PPS. 0 l 10 16 377 0.0000 0.0032 0.0003 SHM(0) .GPS. 0 l 56 64 377 0.0000 -14.8343 36.1163 +andromeda.cs.pu .CDMA. 1 u 29 1024 377 77.1681 -2.2166 0.6409
Explanation: This is near-real-time live output that lists the various "clocks" which my time server is synchronizing to, along with various statistics about the clocks.
The first clock, listed as SHM(1) and .PPS, is the local GPS unit's PPS (pulse per second) output. This is a pulse on one of the Raspberry Pi's GPIO lines, very precisely synchronized to the start of the GPS system's second. It should have zero delay (delay measures the network delay, which is by definition zero for a locally attached clock that doesn't use the network, even though some will insist there is still a tiny bit of propagation delay due to physics.) The "offset" is the difference between my computer's internal clock and the GPS unit's PPS signal, in milliseconds, and is normally very small. But it is usually nonzero, mostly because of temperature-related instabilities in the computer's local clock (the computer is in a garage with no heating nor air conditioning). An offset of 0.0010 would be one microsecond, or one millionth of a second. The "jitter" is average difference in offsets between one sample and another, again measured in milliseconds.
The second clock, listed as SHM(0) and .GPS., is the serial data stream of ASCII characters from the local GPS unit. This is delivered to the computer in NMEA format. Since the PPS output we described earlier is just a simple pulse each second, it identifies when the second starts, but it doesn't identify which second is starting. The serial data stream solves this problem. It tells the time and date in ASCII characters. It can be relied on to give the time accurate to the nearest second, but because serial characters arrive relatively slowly on the data line, this has relatively high jitter, and typically will have an offset in the tens or hundreds of milliseconds.
Those two data outputs of the GPS work together to get the precise time. If you can imagine the GPS saying: "At the tone, the time will be Tue May 21 19:25:51 UTC 2019 ... BEEEEP.", the .GPS. serial data stream provides the date and time, while the .PPS. pulse on GPIO data line provides the BEEEEP.
Following those two local clocks, there's one more clock obtained from a public pool of network time servers out on the Internet. This will have a fairly high delay, often in the 50-100 millisecond range, sometimes worse. The offset and jitter are usually significantly worse than the local PPS clock, because of various network issues. Why do I have this extra time server? It's because the NTP algorithms don't like having just two clocks. If we used just the .PPS. and .GPS. clocks, they would probably disagree, and NTP runs the risk of labelling them as "false tickers", refusing to sync to either. By including another clock or two as a referee, the NTP algorithm will figure out that the .PPS. clock is trustworthy, and sync to it.
This extra clock also provides a sanity check and a fallback in case my GPS unit should ever fail.
The relevant portion of /etc/ntp.conf follows:
# Prefer the precise clock at unit 1 over the imprecise one at unit 0. # GPS PPS reference (NTP1) refclock shm unit 1 refid PPS prefer minpoll 4 # GPS Serial data reference (NTP0) refclock shm unit 0 refid GPS time1 0.550 noselect # Emperically determined that serial GPS is about .55 seconds fast, on average # (with lots of jitter), by setting "time1 0.550", it keeps the clocks # close enough to avoid being rejected as a false ticker, we hope. # Check servers server 0.us.pool.ntp.org iburst minpoll 10
The output at the top of the page is generated in near real time. Refresh the page to see the numbers update a little bit. The date/time stamp should obviously update. The other lines will update at the interval indicated in the "poll" column. That is, typically, the .PPS. clock's row will update every 16 seconds, while the last row will probably update every 1024 seconds.