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

Unruh unruh-spam at physics.ubc.ca
Thu Mar 26 05:00:31 UTC 2009


Dave Hart <davehart at gmail.com> writes:

>On Mar 26, 2:39=A0am, 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 recogni=
>ze
>> 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:

OK, once it becomes the source, it should stay the source. Once the local
clock is within half a second, it is not going to suddenly jump by a second
(well not very often).



>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

That sounds like a bug. Once a PPS has taken control, it should maintain
control unless there is overwhelming evidence that it has lost control (Ie
jumped by a second). Computer clocks are relatively good flywheels.

>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