[ntp:questions] Win7 NTP-dev NMEA User Mode PPS, Freq_Mode Not Working

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Thu Feb 27 16:44:06 UTC 2014

On 2014-02-27 05:21, David Taylor wrote:
> On 27/02/2014 08:37, Brian Inglis wrote:
>> Hi folks,
>> Tried testing latest NTP-dev 4.2.7p424 from DJT site on Windows 7 x64
>> with UTC RTC
>> and Garmin 18x LVC with DCD PPS sending RMC only in NMEA 2.3+ mode @ 9600.
>> NTPd running at realtime priority affinity set to processor 3 with both
>> dev and stable.
>> NMEA user mode PPS timestamp never reported - works fine on stable
>> before and after dev test.
>> Freq_Mode never reported - works fine on stable before and after dev test.
>> Frequency and offset ran away with no sign of return towards hardware
>> drift of +0.9PPM.
>> Leap_Event reported on ntpq -c rv instead of Clock_Sync.
>> Event c016 06 restart reported in log after c012 02
>> freq_set on dev
>> but vice versa order on stable.
>> Event c615 05 clock_sync reported in log 30s after c61c
>> 0c clock_step on dev
>> c614 04 freq_mode reported in log 30s after c61c 0c
>> clock_step on stable,
>> but on stable c412 02 freq_set then c415 05 clock_sync
>> reported 15mins later.
>> Anyone any ideas what might be causing this/these discrepancies between
>> dev and stable?
> Brian,
> I don't know whether it helps, but I see this on a Windows-8.1/64 PC running the signed kernel-mode PPS driver.  It's a GPS 18x LVC which is driving it, powered of 5V from a USB port.  I don';t know at the moment what the Garmin is set to output.  It's on the latest firmware: 3.90. Realtime priority (set by the program) and affinity mask is for all rour processors (i5-3330 chip).
> C:\Users\David>ntpq -crv stamsund
> associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
> version="ntpd 4.2.7p424 at 1.2483-o Feb 24 10:38:46.00 (UTC-00:00) 2014  (1)",
> processor="x86", system="Windows", leap=00, stratum=1, precision=-22,
> rootdelay=0.000, rootdisp=1.120, refid=PPS,
> reftime=d6b9a9e9.bb0f6f05  Thu, Feb 27 2014 12:11:21.730,
> clock=d6b9a9f1.d7ef24ca  Thu, Feb 27 2014 12:11:29.843, peer=18499, tc=4,
> mintc=3, offset=0.019701, frequency=-6.425, sys_jitter=0.013465,
> clk_jitter=0.020, clk_wander=0.000, tai=35, leapsec=201207010000,
> expire=201406010000
> Sorry for the wrap!
> General performance of that PC is here:
>    http://www.satsignal.eu/mrtg/performance_stamsund.php
> Not sure how to proceed, but if I can be of help, I will.

That is similar to what I expect on dev and get on stable:

associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
version="ntpd 4.2.6p5-o Dec 24 23:49:50.41 (UTC-00:00) 2011  (1)",
processor="x86", system="Windows", leap=00, stratum=1, precision=-22,
rootdelay=0.000, rootdisp=0.299, refid=GPS,
reftime=d6b9e537.e1845713  Thu, Feb 27 2014  9:24:23.880,
clock=d6b9e538.e95000cb  Thu, Feb 27 2014  9:24:24.911, peer=36166, tc=4,
mintc=3, offset=0.021, frequency=0.887, sys_jitter=0.028,
clk_jitter=0.018, clk_wander=0.000

but offset, frequency, and therefore rootdisp kept increasing.

Possibly clk_jitter, definitely sys_jitter and ref clock jitter
were pegged at 0.976.../0.977, which seems to be a symptom of
this runaway condition, and also occurs on stable if NTPd process
is restarted rather than the system being restarted.

Can not use signed kernel mode PPS driver (32 bit?) with my
64 bit PCI serial card drivers - it seems to be ignored.
Followed your PPS serial instructions, for which thanks,
and others around, and also fiddled a lot, with no indication
anything had any effect.

Take care. Thanks, Brian Inglis

More information about the questions mailing list