[ntp:questions] Assistance with PPS on Windows
martin.burnicki at meinberg.de
Mon May 23 15:34:13 UTC 2011
sorry again for the late reply.
Ken Link wrote:
> Hi Martin,
> Thanks for the reply. I see +/-0.003s in MbgMon, under Time
> Difference. With NTP off, it appears to go from 0.003 to 0.002 to
> 0.001 to 0.000, stay at 0.000 for a few seconds, then bounce back to
> +/-0.003 and repeat. I assumed this was normal behavior as long as
> MbgMon continues to correct the time difference.
This sounds like the IRIG input signal is not very accurate, and steps by a
few milliseconds from time to time.
If you used a Meinberg GPS card as IRIG source to feed the TCR511PCI card
and had an oscilloscope available you could compare the 1 PPS signal
generated by the TCR card from the IRIG signal to the 1 PPS signal
generated by the GPS card, and you would see the signals only differ by a
couple of microseconds. In this case you'd see the time difference go down
to 0.000s and stay there, only the time adjustment rate would tell there
are tiny corrections applied to the system time.
I don't know if your IRIG generator has a 1 PPS output, but if it has you
could do the same.
Also, you could run the time adjustment service to see how the time offset
decreases to 0.000, then disconnect the IRIG input signal and see if the
offset stays at 0.000. If it does, but starts jumping again by a few
milliseconds if you re-connect the IRIG input signal then you can be sure
the IRIG signal jitters.
If this is the case then using the 1 PPS output signal of the TCR card to
discipline the Windows system time using ntpd/PPS would not help since the
PPS signal would follow the millisecond steps in the IRIG signal.
> The second I start NTP (with only a stratum 0 local clock and a drift
> file configured) I see a Time Service Warning in MbgMon, "System time
> adjusted by another program!". This leads me to believe NTP is still
> trying to discipline the local clock.
This happens if ntpd has been configured to use, and actually also finds a
drift file, in which case it starts to apply the "last known good drift
compensation" from the drift file to the Windows system time and thus works
against the Meinberg time adjustment service, which means ntpd sets the
Windows tick value in regular intervals to the value computed from the
drift file. This is the reason for the warnings from the Meinberg service.
The solution is to comment out the drift file entry in the ntp.conf line,
and restart ntpd with only the local clock configured.
> I also see the Time Difference
> increase more frequently, but MbgMon continues to adjust it back down
> to 0.000. I am guessing the increased jitter as seen from a peer of
> this system is due to both time services trying to discipline the
> local clock. Is there a parameter I can add to the NTP configuration
> to force NTP to stop disciplining the clock, yet still act as an NTP
> server? Someone from the NTP list might know the answer to this.
> Here are some screenshots, if that helps:
> MbgMon warning on System B: http://i.imgur.com/J4OfY.png
You can onlyavoid this warning if you keep ntpd from touching the system
time. And, as far as I know, this is only possible by only configuring the
local clock (with stratum 0) but *not* configuring a drift file or other
> As seen from a third system, System A (serially connected to the
> Arbiter Clock, green) and System B (IRIG B from the Arbiter clock,
> using MbgMon & NTP configured with only local clock, yellow). The high
> jitter is concerning: http://i.imgur.com/7MRKg.png
> Out of curiosity, I added PPS back to the NTP configuration on System
> B with MbgMon still running, just to see how accurate the PPS signal
> was, compared to IRIG B: http://i.imgur.com/4NZn3.png
Of course, if 2 programs pull the saystem time back and forth, or the input
signal provides much jitter, then the system time will also jitter.
So you should really try to find out first if the incoming IRIG signal
jitters, or not.
More information about the questions