[ntp:questions] ATOM falseticker with flag3 enabled

A C agcarver+ntp at acarver.net
Thu Mar 29 02:44:07 UTC 2012


On 3/28/2012 19:32, Dave Hart wrote:
> On Wed, Mar 28, 2012 at 05:34, A C<agcarver+ntp at acarver.net>  wrote:
>> On 3/27/2012 22:07, Dave Hart wrote:
>>
>>> I suspect you will see that when you've used flag3 1, ntpd has
>>> reported time_pps_kcbind failing.  I do see a potential bug in that
>>> code, though.  If you don't get any hits from the fgrep, try removing
>>> line 1259 from ntp_refclock.c:
>>>                         if (errno != EOPNOTSUPP) {
>>> and its matching closing brace on line 1265:
>>>                         }
>>> Then recompile ntpd and see if it then reports time_pps_kcbind failure
>>> with flag3 1.
>>
>>
>> Nothing happened with the recompiled version, it still enabled kernel PPS
>> with no complaints:
>>
>>
>> 28 Mar 05:27:43 ntpd[353]: 0.0.0.0 c012 02 freq_set kernel -77.202 PPM
>> 28 Mar 05:28:00 ntpd[353]: PPS(0) 8024 84 reachable
>> 28 Mar 05:32:13 ntpd[353]: 0.0.0.0 061d 0d kern PPS enabled
>
>
> Thanks for trying that.  I'm still suspicious of the code above.  It
> raises the question of whether failed implementation of flag3 1 should
> also cause the driver to not use PPSAPI at all, which I think is the
> effect of the return 0.
>
> Getting back to what you're seeing, it appears to me to be a bug
> (likely in ntpd) interacting with PPSAPI hardpps on NetBSD 5.1.  I
> presume without flag3 1, your PPS(0) reach never changed from 0?  And
> that adding flag3 1 changed it so it became 377 eventually?


Actually no, without flag3 the reach still became 377.  PPS is reachable 
regardless of flag3.
>
> With that in mind, would you please re-test as needed to document the
> unexpected change in behavior in a http://bugs.ntp.org/ report?
>
> There are several interesting paragraphs in the PPS driver doc:
>
> +++
>
>
> The driver normally operates like any other driver and uses the same
> mitigation algorithms and PLL/FLL clock discipline incorporated in the
> daemon. If kernel PLL/FLL support is available, the kernel PLL/FLL
> clock discipline can be used instead. The default behavior is not to
> use the kernel PPS clock discipline, even if present. This driver
> incorporates a good deal of signal processing to reduce jitter using
> the median filter algorithm in the driver. As the result, performance
> with minpoll configured at 4 (16s) is generally better than the kernel
> PPS discipline. However, fudge flag 3 can be used to enable the kernel
> PPS discipline if necessary.
>
> This driver is enabled only under one of two conditions (a) a prefer
> peer other than this driver is among the survivors of the mitigation
> algorithms or (b) there are no survivors and the minsane option of the
> tos command is 0. The prefer peer designates another source that can
> reliably number the seconds when available . However, if no sources
> are available, the system clock continues to be disciplined by the PPS
> driver on an indefinite basis.
>
> A scenario where the latter behavior can be most useful is a planetary
> orbiter fleet, for instance in the vicinity of Mars, where contact
> between orbiters and Earth only one or two times per Sol (Mars day).
> These orbiters have a precise timing reference based on an Ultra
> Stable Oscillator (USO) with accuracy in the order of a Cesium
> oscillator. A PPS signal is derived from the USO and can be
> disciplined from Earth on rare occasion or from another orbiter via
> NTP. In the above scenario the PPS signal disciplines the spacecraft
> clock between NTP updates.
>
> In a similar scenario a PPS signal can be used to discipline the clock
> between updates produced by the modem driver. This would provide
> precise synchronization without needing the Internet at all.
>
> +++
>
> Note the condition of hardpps continuing to discipline the clock when
> there are no survivors does not match your configuration, but the
> result is similar -- the kernel loop remains locked to the PPS
> directly without further assistance from ntpd.  It seems likely to me
> the correct fix is going to bring the behavior of ntpd in line with
> the documentation.

Without flag3 it appears that ntpd does the heavy lifting but is unable 
to use the PPS unless a prefer peer is set.  With flag3 enabled, PPS is 
running without a prefer peer.


>
> Thanks,
> Dave Hart
>



More information about the questions mailing list