...
- GPSdiff: The time difference, in seconds, between the time-tag that was assigned to a RMC message and the date and time that is contained within the message. The time-tag assigned to a message sample is the value of the system clock at the moment the first byte of the message was received. For example, a value of 0.6 secs sec means that the data system assigned a time-tag to the RMC message that was 0.6 seconds later than the time value contained in the message. GPSdiff will be effected by processing lags within the GPS, DSM data sampling lags, and the drift of the DSM system clock relative to the clock within the GPS receiver. As discussed above, GPSdiff is not a precise measurement of clock differences and is not used to adjust the system clock. It gives a crude value of the agreement of the clocks and possible effects of I/O buffering in the data system. When 5 minute statistics are computed, the maximum and minimum values of GPSdiff for each 5 minute period are written to the output NetCDF files as GPSdiff_max and GPSdiff_min.
- GPSnsat: number of satellites being tracked by the receiver, that is, the number of satellites whose signals are used in the its time and location solution. GPSnsat in the NetCDF files and plots is a 5 minute mean.
NTP on the DSM is configured to log information about time-keeping in a "loopstats" file. See http://www.eecis.udel.edu/~mills/ntp/html/monopt.html
for information on the NTP monitoring options.
- NTPClockOffset: the estimated offset of the GPS time from the data system time. A positive value indicates that NTP is estimating that the GPS clock is ahead of the system clock, i.e. the GPS showing a later time than the system clock. The maximum, minimum and mean values of NTPClockOffset in each 5 minute period are computed and written to the NetCDF files and plotted as NTPClockOffset_max, NTPClockOffset_min and NTPClockOffset.
- NTPFreqOffset: the correction applied to the system clock frequency in parts-per-million, a positive value indicates that NTP has determined that the system clock oscillator is slow and the frequency offset is being added to the system clock values. The NetCDF files and plots contain 5 minute means of NTPFreqOffset.
The NTP logs have not been recorded consistently since the beginning of the project. Year 2010 data from May 3 to August 12th and Oct 14th to November 9th are available, as well as all data from April 9, 2011 onward.
...
Replacement of Garmin
...
GPS
On April 12, 2011 the old Garmin GPS 25-HVS at the tower was replaced with a much newer Garmin 18x-LVC model. The model numbers are shown in the $PGRMT messages, where the time is UTC:
...
The following plot is for the old 25-HVS model for 3 days prior to the swap:
The NTPClockOffset _max ranges from approximately -1000 100000 to 50000 microseconds during that this period. The upward spikes in NTPClockOffset _max are simultaneous with positive jumps in GPSdiff_max, up to as much as 2.5 seconds. These jumps in GPSdiff_max also seem to happen when the number of tracked satellites changes, indicating that internal processing lags in the 25-HVS cause it to report late. It is unknown if the PPS signal is effected by these events.
The following plot shows a close up of one of the clock offset spikes using un-averaged data:
At these moments, NTP estimates that the system GPS clock is early relative to the GPSearlier than the system clock, and starts to correct for the error by speeding up slowing down the system clock, seen as the positive spike due to the negative spikes in NTPClockOffset and NTPFreqOffset. When the GPS recovers from its delayed reporting, NTP then NTP sees that sees positive values for NTPClockOffset and adjusts the system clock has gotten ahead of the GPS, reports a negative NTPClockOffset and gradually returns to the previous frequency offset.
After installing 18x-LVC, the NTPClockOffset is in a much smaller range, from -10 70 to 25 microseconds:
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.
...
The periodic spikes in GPSdiff_max up to 1 second that occur at 23:00 local time and last about an hour, are simultaneous with the network transfer of the day's data files from the DSM to the RAL server. These indicate increased sampling buffering and latency is happening at these times, which needs to be investigated and improved.
At these times there is also a little bump in NTPFreqOffset. I can think of two possible causes of this. It could be due to increased interrupt load at these times, causing increased latency in the interrupt function that is called in response to the PPS interrupts. An increase in the delay of response to PPS interrupts should cause NTP to think that the GPS clock has fallen behind the system clock, but the NTPClockOffset at these times is positive, and the slope of NTPFreqOffset is positive, indicating that NTP thinks the GPS clock is ahead.
A close-up of the file transfer on April 14, 23:00 shows several events where NTPClockOffset first has a negative spike, indicating that NTP has determined that the GPS clock is behind the system clock and starts to slow down the system clock. These down spikes appear to be due to a delay in the response to a PPS interrupt. The interrupt latency appears to be short lived, because the NTPClockOffset becomes positive, and the system clock is re-adjusted. The April 14 transfer is shown in this plot:
In July, the clock behaviour during the file transfer is similar, but the initial increase in NTPClockOffset and a rising slope in NTPFreqOffset, might be due to Alternatively, the bump could be caused by increased heating of the system clock oscillator, due to increased CPU load during the file transfers. The sign of NTPClockOffset is consistent with a heating effect, as described above. Also, when the ambient air temperature is very cold, the bump is diminished, or has the opposite slope. So my thinking at this point is that the bump is caused by increased oscillator heating.Wild conjecture?
ppstest and ntpq
...