On Wed, Mar 28, 2012 at 05:34, A C <agcarver+...@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?
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.
Thanks,
Dave Hart
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
