[ntp:questions] Strange jumps in PPM

A C agcarver+ntp at acarver.net
Fri Aug 23 02:53:39 UTC 2013


On 8/22/2013 19:01, E-Mail Sent to this address will be added to the 
BlackLists wrote:
> A C wrote:
>> BlackLists wrote:
>>> Harlan Stenn wrote:
>>>> I'd love to see NTP be able to query and use this sort of information.
>>>
>>> Several of the NMEA sentences have fix quality,
>>>    for binary Refclock drivers if the feature exists,
>>>    there is sure to be packets that include the fix quality.
>>>
>>> I guess we'd have to look at the driver source to see if
>>>    if make use of any of the fix quality fields.
>>>
>>> Of the messages it appears the NMEA driver supports,
>>>    GPRMC, GPGGA, GPGLL, GPZDG, PGRMF
>>>     Have some variety of detail of Fix Quality
>>>
>>>    GPZDA Does NOT have fix quality
>>>
>>>     So the advantage of using _only_ ZDA's compact / short sentence
>>>      to get date & time, is slightly devalued by not getting any
>>>      quality indications?
>>>
>>>
>> Unfortunately this doesn't help the ATOM driver.
>>   In my case I have to feed PPS in separately via ATOM.
>>   So going back to the original suggestion by Mike,
>>    having a way to feed information about nominal system
>>    behavior directly to the driver would be great.
>
> <refclock_atom.c>
>   * This driver is subject to the mitigation rules described in the
>   * "mitigation rules and the prefer peer" page. However, there is an
>   * important difference. If this driver becomes the PPS driver according
>   * to these rules, it is active only if (a) a prefer peer other than
>   * this driver is among the survivors or (b) there are no survivors and
>   * the minsane option of the tos command is zero.
>
>

Right, so ATOM is active if there is an available other source.  This 
does not address the problem of the feed into ATOM (i.e. the actual PPS 
pulse) suddenly having an error and feeding that into ATOM.  In that 
instance under the current implementation (without the mentioned method 
of feeding system parameters) that ATOM will be unaware of any issue and 
continue to discipline the clock until something else finally notices 
(be it the operator or the clock just drifting beyond ntpd's internal 
limits for an automatic shutdown).

What I'm suggesting is a mechanism that lets me inform the ATOM driver 
*in advance* of the state of the system and the expected window of 
nominal operation for the driver itself and the system in general (for 
example PPS offset is never seen past +/- 20us so set the window to +/- 
25us and anything outside of that drop PPS immediately.


More information about the questions mailing list