[ntp:questions] Assistance with PPS on Windows
David J Taylor
david-taylor at blueyonder.co.uk.invalid
Thu May 5 04:50:51 UTC 2011
> It appears all I needed to do was swap the TX and CD pins to get it to
> start polling and synced to PPS. Thanks!
> Now, a behavioral question. Will PPS be selected as the peer if and
> only if the peer marked "preferred" is also synced? What if I want PPS
> to act as a supplement to whichever of the stratum 1+ peers NTP sees
> available and decides to sync to? PPS will be the only stratum 0
> reference source available to this system, but if the preferred peer
> goes down I would expect PPS to continue to correct the jitter of
> whichever other peer NTP decides to sync to (that doesn't seem to be
> the case).
My understanding is that if you have the ATOM driver present and working
(server 127.127.22.1 with serialpps.sys), that is used to refine whatever
server NTP marks with a "*" in the ntpq -p display - the "system peer".
The ATOM driver itself will be marked with an o" character.
> Also, it appears that while the preferred peer continues to be synced
> and polled every 64 seconds, the PPS peer seems to "toggle" from being
> a PPS peer to being rejected nearly every poll (of 16 seconds). Is
> this because the polling rate is different between the PPS source and
> the other sources, or is my serial cable too jittery? The PPS source
> claims to have an offset of +/- 10 ms and a jitter of between 2-3 ms
> depending on the poll.
On a FreeBSD system, the PPS offset shows 0, and the jitter is currently
0.004 (4 microseconds).
On the Windows systems here, PPS offset is typically less than 0.030 (30
microseconds), and the jitter less than 0.050 (50 microseconds). If you
have a Garmin GPS 18x LVC with firmware later than 3.20, it's offset of
the serial data from the PPS can exceed one second, which confuses NTP
about which second the PPS actually was! In such circumstances, you can
stop the serial data being used with a "noselect" modifier:
server 127.127.20.1 minpoll 4 noselect
Even without the kernel-mode serialpps.sys driver, the offset should be
far less than 10 milliseconds, and the jitter far less than 2-3
More information about the questions