On Wed, Nov 16, 2011 at 16:14, A C <[email protected]> wrote: > The PPS is synced almost all the time but the choice of > clock sources moves around from Internet to NMEA. In my case the NMEA > sentences wander but the NMEA clock is always listed as a member of the > accepted clocks (the "+" indicator) even if its own data is so bad that > another clock with similar offset and jitter has been labeled an > outlier/false ticker. > > Note I'm not talking at all about the GPS going away. I'm talking about the > NMEA sentence wandering around dragging the clock with it because it's part > of the overall computed solution.
No, it's not part of the solution. When you have 'o' in the peers billboard, the PPS is disciplining the clock alone. Ignore the rest of the tally codes as long as the PPS is reachable. > By way of example, one of the Internet > servers in my peer list has an offset of 1.887 and jitter of 0.586 and is > labeled an outlier. The NMEA data at that same moment has an offset of > 21.863 and a jitter of 10.290 and it's labeled as accepted. This is because NTP doesn't depend solely on offset and jitter. Root dispersion plays a factor, and reference clocks (even NMEA) have a 0 root dispersion, while your internet sources have root dispersion accumulated from the error in your path to them and their path to the stratum 1 server with the refclock. > What I'm looking to do is to ignore the NMEA in favor of the Internet clocks > as long as they are available then fall back to NMEA in case the network > drops out. > > Before anyone asks, the GPS itself is fine and functioning normally. It was > designed as a PPS reference for a fixed location telemetry network over GSM. > The PPS portion is very accurate but it sacrifices some stability in the > NMEA data to achieve the PPS stability (PPS pulse generation is higher > priority for the CPU than NMEA generation). Since the telemetry device was > intended to be in a fixed location it wasn't considered important to have > very precise NMEA data, only PPS pulses to control timing and slotting. > Jitter on the PPS signal is reported by ntpd to be 0.061 ms (ntpd never > shows jitter numbers lower than this for any source, must be something in > the floating point calculations) and doesn't wander away from that (I can > see the same thing on an oscilloscope, the pulse is quite stable). The reason you see a minimum jitter reported of 0.061 is the precision of the host clock. 1/16384 is 0.061 msec. When ntpd starts, it measures the minimum nonzero difference between subsequent reads of the system clock. Your host clock is in the neighborhood of that value. ntpd converts the precision to a power of 2 -- yours is coming up with precision 2 ** -16, and ntpd is using that precision as a floor to the reported jitter values. In older versions of ntpd (4.2.4 and earlier), the delay values are also floored at the precision, and David Taylor and I have seen evidence that delay flooring may be useful for low-precision host clocks (where ntpd measures precision 2 ** -10 or 0.977 msec). The idea is your host clock is incapable of measuring intervals less than about 2 ** -16 seconds. As a result, ntpd "fuzzes" its reads of the system clock replacing the bits below 2 ** -16 with normally-distributed random noise. It also conveys its -16 precision in its responses to network clients, which factor it into the calculation of the dispersion attributable to the last NTP hop. The response also includes the root dispersion as seen by the server. The root dispersion of a client using your server is the root dispersion your host has calculated plus the peer dispersion your client calculates factoring in the network delay, your clock precision and its clock precision. With a PPS, you should not care about the peer billboard tally codes dancing once PPS is controlling the clock. All you need worry about is ensuring that whether or not you have internet sources, ntpd is able to determine the seconds numbering so it can use the PPS. From your report that the NMEA data is arriving within +/- 50 msec of the PPS, this should be a slam dunk, and there should be no need to even use a separately-listed PPS source in ntp.conf -- you should be able to to use a single NMEA refclock with PPS enabled, and thereby not need prefer anywhere. NMEA will number the seconds for its associated PPS. Note the NMEA driver supports two different time fudges. fudge time1 applies to the PPS signal, fudge time2 to the NMEA end-of-line timestamp. time2 compensates both for the systemic delay after the top of the second before the NMEA sentence being used starts arriving, and for the time to transmit that sentence through its terminating CR/LF. fudge time1 compensates for systemic delay of your system in timestamping the PPS, including cable delay and debouncing delay in the UART before it recognizes the state change of CTS, and delay between the UART asserting the interrupt and the interrupt routine's execution, and the time to actually read the system clock. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
