[ntp:questions] Assistance with PPS on Windows
klink at numberzero.org
Wed May 18 14:57:52 UTC 2011
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.
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. 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
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
On Wed, May 11, 2011 at 12:12 PM, Martin Burnicki
<martin.burnicki at meinberg.de> wrote:
> Hi Ken,
> sorry for the late reply. I'm currently on a business trip.
> Ken Link wrote:
>> Hi Martin,
>> We had considered using the time adjustment service from the driver
>> package at one point, but it seemed to conflict with NTP's
>> configuration at the time. If I disable NTP entirely and only use
>> MbgMon and it's time adjustment service, things look great and the
>> clock is synced to +/- 0.003s from the IRIG signal.
> Hm, 3 *milliseconds* is worse than it should be. Where do you see this
>> However I can't do
>> that for two reasons:
>> 1) I would like to share this highly accurate time as an NTP stratum 1
>> peer (as well as verify it's accuracy by running NTP with multiple
>> peers configured), but when I run NTP and the MbgMon time adjustment
>> service at the same time, NTP tries adjusting the clock and causes a
>> drift of a few hundred msec and high jitter because the two services
>> are fighting over the clock.
> Hm, the configuration we suggest under Windows is to let the Meinberg time
> adjustment service discipline the Windows system time, and run ntpd in a
> configuration with local clock at stratum 0 only, so ntpd doesn't touch the
> system time but makes the synchronized system time available on the
>> 2) In the case where the IRIG signal fails or is inaccurate (e.g.
>> Arbiter clock becomes unlocked from GPS signal) there is no
>> redundancy, validation of correct time/clock discipline, or other time
>> server to connect to unless I am running NTP, which goes back to point
>> In a perfect world I could run MbgMon's time adjustment service and
>> NTP together (with multiple peers), NTP won't touch the clock until
>> the IRIG signal is determined to be bad (loss of IRIG signal, loss of
>> GPS signal at the clock, or local clock is rejected when compared to
>> other peers), and other peers can rely on this computer for accurate
>> and stable time via NTP.
>> Because we couldn't figure that out, we decided to give PPS a try. Is
>> there a way to configure NTP to play nice with MbgMon?
> See above. I must admit there is no possibility for redundancy for ntpd in
> the configuration mentioned above. As soon as you configure one or more
> additional time sources for ntpd ntpd would start to adjust the system time
> and thus work against the time adjustment service from the driver package.
> So maybe what you are trying is helpful in your case. Anyway, I thought I'd
> like to hear about the nature of the problems you have encountered.
> Martin Burnicki
> Meinberg Funkuhren
> Bad Pyrmont
> questions mailing list
> questions at lists.ntp.org
More information about the questions