Drift

One of my goals with the RTC Pi Hats was to have a more stable local frequency. This is useful when you can't reach your upstream clock.

GPS modules lose signal from time to time, especially when your antenna is less than perfect. Mine lost lock for 2 hours and 29 minutes, so it stopped its PPS signal. I have two NTP servers connected to this GPS PPS, and they ran off their internal clocks until the PPS came back.

The gap in the graph shows where the data is missing. You can also see the offset that came from the local clock drifting.

The two NTP servers connected to this GPS are using different clocks. The one named "sandfish" is an x86 machine with a boring normal internal clock. The one named "pi-squared" is a Raspberry Pi 2 with one of my RTC Pi Hats (with TCXO). There are two other NTP servers on my LAN: "odroid64" and "beaglebone". These two other NTP servers have their own GPS modules and did not lose lock during this time frame. These offset data are from a third machine, a stratum 2 server with another RTC Pi Hat.

During the GPS outage, sandfish gained 170.4us (19ppb) and pi-squared lost 64.3us (7ppb). The TCXO was 2.6x better than the normal internal clock for this test.

Unrelated to this, you can see the beaglebone system has a lot of jitter over the LAN compared to the other sources.

The temperature was pretty stable during this time period. It changed 0.6F/0.4C. If it had changed more, the TCXO would have had a larger advantage.

Additional information: sandfish has the default "maxclockerror" setting (1ppm), and pi-squared's configuration is "maxclockerror 0.075". This sets the rate at which "Root dispersion" (estimate of local error) increases. Right before getting back in sync, sandfish's root dispersion was 9.018ms and pi-squared's was 0.686ms. Root dispersion is a pessimistic estimate of error so downstream clocks can prefer better sources of time.