[ntp:questions] Stick to PPS, even if the prefer server fails
Unruh
unruh-spam at physics.ubc.ca
Sat Mar 28 03:13:12 UTC 2009
mills at udel.edu (David Mills) writes:
>Bill,
>The NTPv4 model is that the server does not prejudge what the client is
>prepared to accept. The synchronization distance includes all credible
>contributions to the maximum error budget, including the increase in
>maximum error due to the frequency tolerance of the server timebase.
>This is clearly expressed in the specification along the the expectation
>that a client (requirement for a secondary server) that if the distance
>eexceeds the selection threshold, the server should not be considered by
>the selection algorithm.
>The client is free to adjust the selection threshold to fit its
>requirements. This model apples to all sources, including the atom
>driver. The server distance itself starts at the current value of the
>system peer at the last selection and then increases from there, even if
>all sources are lost. A dependent client will disregard the server when
>the distance exceeds its selection threshold.
Ah, so the atom driver is weird in that it is not regarded as a valid
source, its associated peer is regarded as the source, and if the peer is lost, the
"distance" keeps increasing via ntp's algorithm. Thus after a while ntp
will say that the PPS source has such a large error that clients will
disregard it. That is of course bizarre, since a PPS source typically has a
far far smaller error than do any of the prefer peers.
I think that this is again a design flaw in the atom driver, and again tips
the balance toward using something like the shm refclock driver instead of
atom. At least the shm refclock is treated like a clock in its own right
and leaves it to the user, via whatever feeds the shm, to decide how to
decide when the PPS has become unreliable.
>I am happy to continue this discussion, but only if you read the
>specification.
I think this is an issue of how the atom driver treats the specification,
not of the specification itself.
>Dave
>Unruh wrote:
>>mills at udel.edu (David Mills) writes:
>>
>>
>>
>>>Bill and John,
>>>
>>>
>>
>>
>>
>>>To Bill: Once upon a time several reference clock drivers I wrote had
>>>their own idiosycratic PPS support. There are over forty now in the
>>>driver collection. Years ago I pulled PPS support from all the drivers I
>>>wrote in favor of the atom driver. Most drivers can be used with the
>>>atom driver; the NMEA driver does use the $GPGSA sentence presumably to
>>>police the PPS, but there is no evidence the other GPS drivers do. The
>>>SHM driver you cite does much the same thing as the atom driver to
>>>monitor the offset, but so far as I can see does not groom the signal
>>>itself. Years ago I accidently plugged a signal generator in the PPS and
>>>the kernl went nuts.
>>>
>>>
>>
>>I am sure it would. However, that is not a failure mode one should be too
>>concerned about. However, on my GPS PPS every once in a while it will issue
>>10 pulses in one second. No idea what is causing this noise, but I have
>>seen it on two versions of the GPS18. It is certainly true that the driver
>>should do somethingabout this. (It does not however seem to caused any
>>great problem with my system running from that source via the shm driver,
>>perhaps because it throws away 60% of inputs over the 16 sec poll interval.
>>
>>
>>
>>
>>>You have a flawed interpreation of the NTP algorithms with respect to
>>>the synchronization distance and selection threshold. There is no need
>>>to wait for one day in seconds. That went away with NTPv4. As for a
>>>
>>>
>>
>>That was put in there only if the person wanted to allow the PPS to
>>freewheel but only for a limited time (one day in my example). Ie, the PPS
>>source is assumed to be fine for 1 day even if no prefer peer is selected.
>>
>>Whether there is otehr code in teh atom driver which relies on their being
>>a prefer peer associated with the PPS I do not know.
>>
>>
>>
>>>sticky bit, that would not be hard to add once things like flag glut are
>>>overcome, but from my experience here I would not recommend it for use
>>>in a public server. It is not as simple as you think, as things like the
>>>syncrhonization distance have to be mitigated, etc.
>>>
>>>
>>
>>
>>
>>>To John: I suspect you know that all LORSTA stations run by the Coast
>>>Guard include in the weekly announcement series a time-of-coincidence
>>>(TOC) second at which the epoch of the second is equal to the epoch of
>>>the GRI. My Astron LORAN-C receiver, which was modified by the Coast
>>>Guard, flashes a light at the TOC. The TOCs and the intervals between
>>>them vary up to several minutes depending on the GRI of the chain. I
>>>made provisions for the TOC in the LORAN-C receiver I built some years
>>>ago, but never completed the code to exploit them.
>>>
>>>
>>
>>
>>
>>>Dave
>>>
>>>
>>
>>
>>
>>>Unruh wrote:
>>>
>>>
>>
>>
>>
>>>>jra at febo.com (John Ackermann N8UR) writes:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>David Woolley wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Unruh wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I have now looked at the refclock_atom source and indeed, it demands that a
>>>>>>>prefer clocksource is available, and ignores the PPS if it is not. This I
>>>>>>>believe is a bug, or at least a design infelicity. You could either hack
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>I suspect the reasoning may be that both normally come from the same
>>>>>>radio clock which will free-run the PPS when it loses a signal, so that
>>>>>>detecting the failure of the NMEA data is the only way of telling that
>>>>>>the PPS data is unreliable.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>More than that, some PPS sources don't have an accompanying timecode, so
>>>>>they need another source to provide the coarse time. This does cause
>>>>>some interesting design challenges because it makes the PPS reliant on
>>>>>an external source.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>A couple of years ago I tried defining multiple prefer peers to improve
>>>>>the reliability, but never got that working in a reliable way.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>I'd like to see one of two solutions: (a) the ability to define
>>>>>multiple prefer peers, such that failure of one would cause a switch to
>>>>>another; or (b) an option that would require an external sane source for
>>>>>initial sync, but once the time is known to the second, continue relying
>>>>>on the PPS even if the prefer server goes away.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>The second would be trivial to apply. Just stick in a flag which gets set
>>>>once the initial external source has converged to within .1 sec say, and
>>>>if set it stays set and the PPS source gets used if it is set. If you
>>>>really worry, you could augment the flag everytime the prefer peer was
>>>>unavailable ( resetting it every time it was) and not use PPS if that
>>>>counter got greater than 86400 say ( one day) This is about a three line
>>>>change to the atom driver.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>BTW -- this is a real-world issue, at least for my definition of
>>>>>"world". Two of my NTP servers have this problem. One syncs from a
>>>>>Cesium atomic clock, and the other from a LORAN-C receiver. Both those
>>>>>sources provide PPS but no accompanying timecode.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Use the shmpps code with the refclock_shm driver. It will wait until the
>>>>time source is reported to have an offset of less than .25 sec, and then
>>>>start the shm report of the PPS source. Thereafter it will continue to use
>>>>the PPS source as a normal source, which you can make the preferred source.
>>>>
>>>>
>>>>
>>>>_______________________________________________
>>>>questions mailing list
>>>>questions at lists.ntp.org
>>>>https://lists.ntp.org/mailman/listinfo/questions
>>>>
>>>>
>>>>
>>>>
>>
>>_______________________________________________
>>questions mailing list
>>questions at lists.ntp.org
>>https://lists.ntp.org/mailman/listinfo/questions
>>
>>
More information about the questions
mailing list