[ntp:questions] Request to test patch for ntpd

Richard Steedman richard.steedman at btinternet.com
Sun Feb 1 17:19:11 UTC 2015


On 28/01/2015 17:30, Martin Burnicki wrote:
> Hi all,
>
> several months ago I have opened NTP bug #2592
> "Leap second warning from refclock lost, and time offsets may not be
> accepted if refclock driver uses PPS"
> http://bugs.ntp.org/show_bug.cgi?id=2592
>
> By intensive testing with the current NTP tarball 4.2.8p1-RC1
> http://archive.ntp.org/ntp4/ntp-4.2/ntp-4.2.8p1-RC1.tar.gz
>
> we have found out that a leap second status from a refclock is still not
> picked up in 4.2.8, and even worse, that initial synchronization may not
> work if the initial time offset is in a certain range. See the bug
> report for details.
>
> As far as we have seen there's a simple fix for this. Anyway, I'd like
> to ask if folks who are using refclocks with PPS support could test the
> patch to make sure it doesn't break something else.
>
> To do so, you can just download the tarball mentioned above, then change
> into the base directory and extract this tarball there:
> http://people.ntp.org/burnicki/ntp-2592-ntp_proto.tar.gz
>
> This just overwrite ntpd/ntp_proto.c with a version containing the patch
> mentioned in the bug report.
>
> We have already run the following tests successfully:
>
> - parse driver (driver 8) with built-in PPS enabled
> - parse driver 8 without built-in PPS, but ATOM in addition
> - network peer marked as "prefer", and ATOM in addition
>
> It would be great if some folks who use a refclock with PPS run this
> test and see if everything still works as before, or even better. ;-)
>
> Martin
===========================================

Martin,

I have tested your patch successfully using the NMEA driver with build-in
PPS (i.e. server 127.127.20.1 fudged with flag1=1).

My setup is a Sure Electronics GPS board connected to a Raspberry PI.  The
NMEA data comes over the GPS board's USB serial interface (a Silicon Labs
CP2102) and the PPS output of the GPS board is connected to one of the Pi's
GPIO inputs.

I am *not*, however, able to observe your 'failure to sync' issue when
running ntp4.2.8 without your patch.  If the Pi's clock is set fairly close
to correct time but more than 0.5s adrift from the time signalled by the GPS
board and ntpd is then started, the computer's clock comes into sync
correctly.

I'd be interested in trying to re-create your issue and then see it go away
by applying your patch.  Is there a simple setup that is guaranteed to make
the system fail to synchronise in the manner described in the bug report?

Richard Steedman
 



More information about the questions mailing list