[ntp:questions] Assistance with PPS on Windows

Ken Link klink at numberzero.org
Thu May 5 16:32:25 UTC 2011


Assuming the Delay, Offset, and Jitter column units are msec, after
letting it run overnight and half of the next day I still see PPS with
0 delay, 4.559 msec offset, and 3.123 msec jitter.

The PPS source is the Meinberg TCR511PCI card, as seen here:
http://www.meinberg.de/english/products/tcr511pci.htm

The card itself is accepting the unmodulated IRIG B signal from the
Arbiter 1093C clock, and shows itself as locked and synced with 100%
signal.

I suppose there could be a few reasons why PPS is so bad:

1) The cable used to move the IRIG signal from the clock to the
Meinberg card acts as both the input (of the IRIG signal into the
card's serial port) as well as the output (of the PPS signal into COM1
of the computer). We cut into the middle of the cable and made a tap
with another RJ-45 endpoint which we plugged into the COM1 port. The
sheer ugliness of the cable itself might be the cause.

2) The Meinberg card also outputs the standard Meinberg ASCII timecode
over the serial cable...so there are technically three different
signals travelling over this cut-into cable: IRIG B, PPS, and
Meinberg's ASCII timecodes. The pins must be different, otherwise the
card wouldn't be able to lock onto the IRIG B signal, right?

3) The system is normally under pretty heavy load, being only a single
core system (with hyperthreading) and it averages 60-100% CPU usage
most of the time.

The problem is that the card only has one serial port and needs to
accept unmodulated IRIG B as well as output PPS...our solution was to
cut into the cable and tap another line out of it, so we can also
connect it to the COM1 port. However, that means the IRIG signal is
reaching both the Meinberg card as well as the PPS driver, potentially
causing interference.

Thoughts? I realize Windows isn't the best system for time accuracy,
but I just want to see how close/stable it can get.

Thanks,
Ken

On Wed, May 4, 2011 at 11:50 PM, David J Taylor
<david-taylor at blueyonder.co.uk.invalid> wrote:
>> 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!
>
> Great!
>
>> 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.
>>
>> Thanks,
>> Ken
>
> 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 milliseconds.
>
> Cheers,
> David
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions
>



More information about the questions mailing list