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

Brian Inglis Brian.Inglis at Shaw.ca
Thu Feb 27 21:39:41 UTC 2014


On 2014-02-27 09:44, Brian Inglis wrote:
> 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 0.0.0.0 c016 06 restart reported in log after 0.0.0.0 c012 02
>>> freq_set on dev
>>> but vice versa order on stable.
>>>
>>> Event 0.0.0.0 c615 05 clock_sync reported in log 30s after 0.0.0.0 c61c
>>> 0c clock_step on dev
>>> 0.0.0.0 c614 04 freq_mode reported in log 30s after 0.0.0.0 c61c 0c
>>> clock_step on stable,
>>> but on stable 0.0.0.0 c412 02 freq_set then 0.0.0.0 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.

Dev peerstats for my GPS ref clock showed NTP maxed out with
offset 31s, jitter 57s, dispersion 7s before I reverted to stable.
Yes those units are *seconds* not ms or us!
Stable peerstats shows daily max offset 60us, jitter 70us,
dispersion 240us, with offset mean < 0.2us, StDev < 15us,
ntpq billboard 0.00n - single digit us.

While that ref clock is my prefer peer for labelling seconds,
I have good backup network servers, their peerstats had offsets
in single digit ms, and those and my ref clock clockstats were
in normal tight ranges, so the control loop should never have
run away that much, even in a dev release!

Anyone have further suggestions for more info or test setup?

-- 
Take care. Thanks, Brian Inglis


More information about the questions mailing list