Monitoring the accuracy of the system clock on a real-time data acquisition system provides useful information about the performance of the system. Hence this long discussion.
...
The serial messages from the GPS are received on serial port 3, /dev/ttyS3. The pulse-per-second square-wave signal (PPS) from the GPS is also connected to the CTS DCD line of that serial port. A patch has been added to the Linux kernel on the data system so that an interrupt function can be registered to run in response to the CTS DCD interrupts. This interrupt function will be called immediately after the rising edge of the PPS signal has been detected by the serial port hardware.
...
NTP on the DSM is configured to log its status in a "loopstats" file. See http://www.eecis.udel.edu/~mills/ntp/html/monopt.html
for information on the NTP monitoring options. The loopstats file includes these variables, which have been merged into the Manitou data archive:
...
The following plot is for the old 25-HVS model for 3 days prior to the swap:
The NTPClockOffset ranges from approximately shows spikes between -100000 to 50000 microseconds during this period, which is much worse than expected for a GPS/NTP reference clock. The spikes in NTPClockOffset are simultaneous with positive jumps in GPSdiff_max, up to as much as 2.5 seconds. These jumps in GPSdiff_max events seem to happen when the number of tracked satellites changes, indicating which indicates that internal processing lags in the 25-HVS cause it to report late. It is unknown if , causing large values of GPSdiff. The extent of this effect on the timing of the PPS signal is effected by these eventsunknown.
The following plot shows a close up of one of the clock offset spikes using un-averaged data:
At these moments, NTP estimates The sudden downward jump in NTPClockOffset causes NTP to think that the GPS clock is earlier than the system clock, and . NTP starts to correct for the error offset by slowing down the system clock, due to as seen in the negative spikes in NTPClockOffsetvalues for NTPFreqOffset. When the GPS recovers from its delayed reporting, NTP then sees positive values for NTPClockOffset and adjusts the system clock ahead.
After installing 18x-LVC, the NTPClockOffset is in a much improved range, from -70 to 25 microseconds:
. NTPFreqOffset is also in a much tighter range, indicating that NTP is applying smaller corrections to the system clock. GPSdiff is also much better behaved, ranging from a minimum of 0.5 to 1.1 seconds. The number of satellites tracked by the new GPS is also generally higher.
Temperature Effects
As expected, the The frequency offset shows a temperature dependence in the system clock oscillator. We do not measure the temperature inside the data system boxenclosure, which is at the base of the tower. The nearest temperature measurement is of the ambient air at 2 meters on up the tower. The top panel in the plot below shows a time series of the air temperature, along with NTPFreqOffset, for a cool 3 day period in April, after the installation of the new GPS. It appears that when the air temperature is below 5 deg C, the system clock oscillator does not show an obvious temperature relation.
The bottom panel shows a close relationship between the NTPClockOffset and the time derivative of NTPFreqOffset, which, I believe, indicates how NTP adjusts the system clock based on the measured offset. It also enforces the obvious conclusion that we could improve the time-keeping by insulating the CPU from temperature changes.
On a warmer 3 day period in July, where the temperatures were all above 5 degC, the temperature effect on the system clock oscillator is very evident.
...