[ntp:questions] Popcorn on prefer takes out system clock

Dave Hart hart at ntp.org
Wed Mar 7 01:35:16 UTC 2012


On Wed, Mar 7, 2012 at 00:15, A C <agcarver+ntp at acarver.net> wrote:
> It did look a lot like a very large binary number but I'm not dismissing
> anything at the moment.

Whatever is triggering the 2^31 second offset should be the first
problem you debug, IMHO.

>  In any case, whether it should or should not have
> triggered slewing, the reality is that it did actually cause a slew.  The
> PPM offset was stable at about -77.8 when the event occurred and within two
> loop cycles (16 seconds) it was -36.  It couldn't recover from that mess,
> the clock was just out of control.

Are you using the kernel loop discipline?  If ntptime reports
nondefault numbers, you are.  In that case, I'd suggest switching it
off using "disable kernel".

ntpd's daemon loop discipline in 4.2.7 limits the sum of its
instantaneous frequency adjustments to +/- 500 PPM.  The kernel loop
discipline uses integer math only and is responsible for calculating
the frequency given offset estimates from ntpd.  I'm assuming your
overspeed frequency changes are due to overflow in the kernel loop
likely triggered by the insane 2^31 s offset passed from ntpd.  Once
the insane input bug is resolved, you could re-consider using the
kernel loop discipline.  In addition to "disable kernel" you should
avoid using "flag3 1" with refclocks such as NMEA or PPS where it
enables direct PPS sync by the kernel loop discipline for now.

> I will try with NMEA and see if I can go without a preferred peer and still
> have PPS.  However, that eventually negates my use of SiRF binary so it's
> not exactly a viable long term solution.

I think it's a mistake to presume your end solution configuration as
you work through problems.  Using SHM on non-x86 systems is a bit of a
gamble at present, as the protocol for read consistency is imperfect
and x86 happens to have very strict ordering constraints which are
intentionally relaxed on other architectures for performance.  By far
most use and testing has been on x86, so the protocol weakness hasn't
been much of a practical issue.  There's been a lot of discussion of
what could be done better for the SHM protocol but not much refclock
code.  I think backwards compatibility would be good, too, but some
big names in ntpd and gpsd disagree and would be fine with a
requirement that ntpd >= version X needs gpsd >= version Y.  It would
simplify the refclock_shm.c code.

Take care,
Dave Hart


More information about the questions mailing list