[ntp:questions] TSIP and PPS can't synchronize after start

David Lord snews at lordynet.org
Thu Dec 27 10:00:02 UTC 2012


Nickolay Orekhov wrote:
> Hello, David!
> 
> This didn't worked with mindist=0.45 and mindist=1.0 also.
> Concerning "fudge time1" - i've tuned it when this sources were declared
> different. So my sources are very close and works fine when they are
> separated.
> Please, could you explain how one and only one time source can become
> falseticker? ( or may be point to the RFC section )
> 
> 2012/12/27 David Lord <snews at lordynet.org>
> 
>> Nickolay Orekhov wrote:
>>
>>> Hello!
>>>
>>> I've got a QNX machine with external Trimble TSIP receiver and PPS going
>>> through serial port ( but supplied by another additional driver ).
>>> Here's my config:
>>>
>>> # midist  : increased minimal distance for PPS reference clocks ( default
>>> 0.001s )
>>> tos mindist 0.128
>>>
>>> # panic   : zero to accept initial big shifts ( default 1000s )
>>> # stepout : how many seconds wait before stepping to spike ( default 900s
>>> )
>>> # step    : step threshold in seconds ( default 0.128s )
>>> tinker panic 0 stepout 60
>>>
>>> # TSIP reference clock
>>> server 127.127.8.2 mode 138 prefer maxpoll 3 true
>>> fudge 127.127.8.2 refid TSIP time1 0.08 stratum 8
>>>
>>> Here's ntpq output:
>>>
>>> # /usr/sbin/ntpq 10.1.1.210
>>>
>>> ntpq> rv
>>> associd=0 status=0018 leap_none, sync_unspec, 1 event, no_sys_peer,
>>> version="ntpd 4.2.7p164 at 1.2483 Mon Sep 10 04:54:12 UTC 2012 (1)",
>>> processor="x86pc", system="QNX/6.5.0", leap=00, stratum=9, precision=-20,
>>> rootdelay=0.000, rootdisp=1284.075, refid=GENERIC(2),
>>> reftime=d4857ad1.534b73e5  Wed, Dec 26 2012 19:32:01.325,
>>> clock=d4857b83.589b9099  Wed, Dec 26 2012 19:34:59.346, peer=0, tc=3,
>>> mintc=3, offset=13.009, frequency=-16.969, sys_jitter=485.290,
>>> clk_jitter=3.690, clk_wander=0.000, last_step=0.000, step_cntr=0
>>>
>>> ntpq> pe
>>>      remote           refid      st t when poll reach   delay   offset
>>>  jitter
>>> ==============================**==============================**
>>> ==================
>>> xGENERIC(2)      .TSIP.           8 l    4    8  377    0.000  -394.19
>>> 459.192
>>>
>> You are a falseticker because offset is more than the mindidt=0.128
>>
>> Depending on your ntpd version I'd suggest setting a  mindist=0.45
>> for a start and monitoring the offset for a while to get a good
>> value for offset variation, after which change your "fudge time1"
>> to middle of that offset range and you will probably then be able
>> to reduce the mindist value.
>>
>>
>> David
>>
>>
>>  ntpq> ass
>>> ind assid status  conf reach auth condition  last_event cnt
>>> ==============================**=============================
>>>   1 37217  913a   yes   yes  none falsetick    sys_peer  3
>>> ntpq> cv 37217
>>> associd=37217 status=0020 2 events, clk_unspec,
>>> device="Trimble GPS (TSIP) receiver", timecode="\x10M-^B\x02\x10\**x03",
>>> poll=30, noreply=0, badformat=0, baddata=1, fudgetime1=80.000, stratum=8,
>>> refid=84.83.73.80, flags=0,
>>> refclock_ppstime="d4857b8a.**89b415be  Wed, Dec 26 2012 13:35:06.537",
>>> refclock_time="d4857b89.**b8000000  Wed, Dec 26 2012 13:35:05.718",
>>> refclock_status="TIME CODE; PPS; POSITION; (LEAP INDICATION; PPS SIGNAL;
>>> POSITION)",
>>> refclock_format="Trimble TSIP",
>>> refclock_states="*NOMINAL: 00:03:51 (97.46%); ILLEGAL DATE: 00:00:06
>>> (2.53%); running time: 00:03:57",
>>> trimble_version="1.16 (1906/2/2)", trimble_iooptions="00 00 23 00",
>>> trimble_satview="mode: 2D-AUTO, PDOP 0.00, HDOP 0.00, VDOP 0.00, TDOP
>>> 0.00,
>>> 2 satellites in view: 01, 11",
>>> trimble_receiver_health="doing position fixes",
>>> trimble_status="machine id 0x5a, Superpackets supported", satellites=2
>>> ntpq> rv 37217
>>> associd=37217 status=913a conf, reach, sel_falsetick, 3 events, sys_peer,
>>> srcadr=GENERIC(2), srcport=123, dstadr=127.0.0.1, dstport=123, leap=00,
>>> stratum=8, precision=-20, rootdelay=0.000, rootdisp=0.000, refid=TSIP,
>>> reftime=d4857b89.b8000000  Wed, Dec 26 2012 19:35:05.718,
>>> rec=d4857b8a.53bba453  Wed, Dec 26 2012 19:35:06.327, reach=377,
>>> unreach=0, hmode=3, pmode=4, hpoll=3, ppoll=3, headway=0, flash=00 ok,
>>> keyid=0, ttl=0, offset=-333.209, delay=0.000, dispersion=347.336,
>>> jitter=421.221,
>>> filtdelay=     0.00    0.00    0.00    0.00    0.00    0.00    0.00
>>>  0.00,
>>> filtoffset= -333.21 -394.19  275.11 -412.30  364.76 -344.66 -393.18
>>>  275.94,
>>> filtdisp=    320.63  377.33  378.43  356.35  437.03  321.96  376.95
>>>  379.26
>>>
>>> ntpq>
>>>
>>> Also here's output from my pps driver:
>>>
>>> # cat /dev/pps0
>>> C 1356529006.540260352
>>> C 1356529007.540283136
>>> C 1356529008.540306176
>>> C 1356529009.540329984
>>> C 1356529010.540353792
>>>
>>> Here you can see that timestamps are in the middle of the second.
>>> I know that PPS driver is working and if i divide PPS and GPS into two
>>> sources everything is fine. Also GPS without PPS also works fine.
>>> If i restart ntpd in most cases it will be ok.
>>>
>>> Please, could you make suggestions on the following questions:
>>>
>>> 1. Why source is falseticker? I thought that source can become falseticker
>>> only if ntpd has two or more sources declared.
>>> 2. Why it can't synchronize in this way ( but works fine with separated
>>> sources and GPS without PPS )

Take a look at the documentation that comes with your source
files. For me its in ntp-4.2.6p5/html/miscopt.html tos options.

eg. for my MSF receiver I have:

tos minsane 3
tos orphan 10
tos mindist 0.01
server 127.127.28.0 prefer
fudge 127.127.28.0 time1 0.024 refid MSFa

along with 2 x local peers and 5 x internet ntp sources

For my Garmin 18x-LVC I had fudge time 0.66 and mindist 0.8.
Without the large values the gps refclock would not
always synchronise.


David



More information about the questions mailing list