[ntp:questions] Stick to PPS, even if the prefer server fails

Dave Hart davehart at gmail.com
Thu Mar 26 03:46:17 UTC 2009


On Mar 26, 2:39 am, Unruh <unruh-s... at physics.ubc.ca> wrote:
>
> So, again I am confused.
> I have
> server tick.usask.ca
> server ntp.ubc.ca
> server 127.127.28.0 minpoll 4 prefer
>
> where 127.127.28.0 is the PPS via shm and this system seems to have no
> problems.
> So again my confusion may be irrelevant (well my confusion certainly is
> irrelevant but my situation may not be.) Or maybe I simply do not recognize
> the problem.
> And why is the pps not the preferred peer?
> (By GPS I assume you mean an NMEA GPS source).

The original poster is using the PPS refclock driver (127.127.22.u,
refclock_atom.c).  The PPS driver knows when the top of the second is,
but does not know which second.  The PPS driver starts out unreachable
until a peer marked prefer is selected and the local clock is within
400ms of that prefer peer, then it trumps and becomes the source:

25 Mar 06:01:56 ntpd[1724]: peer GPS_NMEA(1) event
'event_reach' (0x84) ...
25 Mar 06:02:41 ntpd[1724]: system event 'event_peer/
strat_chg' (0x04) ...
25 Mar 06:02:41 ntpd[1724]: synchronized to GPS_NMEA(1), stratum 0
25 Mar 06:02:41 ntpd[1724]: system event 'event_sync_chg' (0x03) ...
25 Mar 06:02:41 ntpd[1724]: system event 'event_peer/
strat_chg' (0x04) ...
25 Mar 06:02:43 ntpd[1724]: peer PPS(1) event 'event_reach' (0x84) ...
25 Mar 06:03:31 ntpd[1724]: pps sync enabled
25 Mar 06:03:31 ntpd[1724]: synchronized to PPS(1), stratum 0

Since my GPS_NMEA(1) and my PPS(1) are using the same serial port, I'm
not concerned about that setup losing the prefer peer taking out the
PPS.  I'm following this thread with interest, however, as I have done
work to enable the PPS driver on Windows for serial ports (provided a
custom serial.sys that adds CD timestamping is used).  This is not yet
in any NTP release.  On Windows, there is no support for directly
disciplining the system clock with a PPS signal, so as with Thorsten
using stock Linux, if the prefer peer goes dark the PPS will follow
before too much longer, no matter that we no longer have ambiguity
about which second.  Assuming the PPS is still trusted, such as
Thorsten's, that's suboptimal.  At least on Linux patches do exist for
kernel PPS discipline.  I could put a gross hack in serialpps.sys to
force the system time to the exact second on each PPS and expose that
via PPSAPI as kernel time discipline, but that's really ugly on
several fronts, a serial driver has no business interfering with the
OS timekeeping, and I'm guessing that's not hoow a real kernel clock
discipline works, though the effect would be similar.

Cheers,
Dave Hart




More information about the questions mailing list