[ntp:questions] ntpd wedged again

A C agcarver+ntp at acarver.net
Sun Feb 12 07:27:35 UTC 2012


On 2/11/2012 22:22, David Lord wrote:
> A C wrote:
>> On 2/11/2012 07:08, Dave Hart wrote:
>>> On Sat, Feb 11, 2012 at 09:42, A C<agcarver+ntp at acarver.net> wrote:
>>>> On 2/11/2012 01:21, A C wrote:
>>>>
>>>> This is the more recent status though I'm not sure why the PPS is
>>>> marked as
>>>> bad.
>>>>
>>>>> remote refid st t when poll reach delay offset
>>>>> jitter
>>>>>
>>>>> ==============================================================================
>>>>>
>>>>> x127.127.22.0 .PPS. 0 l 5 16 377 0.000 0.002
>>>>> 0.122
>>>>> 127.127.28.0 .GPSD. 4 l 84 128 377 0.000 -30.840
>>>>> 15.522
>>>>> +69.65.40.29 209.51.161.238 2 u 36 128 377 74.436 1.585
>>>>> 0.199
>>>>> -169.229.70.201 169.229.128.214 3 u 111 128 377 37.326 3.009
>>>>> 0.571
>>>>> +198.137.202.16 69.36.224.15 2 u 111 128 377 36.641 1.851
>>>>> 0.400
>>>>> *130.207.165.28 130.207.244.240 2 u 95 128 377 78.266 1.667
>>>>> 0.736
>>>>> -131.144.4.10 130.207.244.240 2 u 40 128 377 85.358 3.798
>>>>> 1.243
>>>
>>> See http://www.eecis.udel.edu/~mills/ntp/html/cluster.html with the
>>> understanding that falsetickers (x in peer tally code in first column)
>>> are those pruned by the cluster algorithm.
>>
>> Ok, that explanation makes some sense but the system is now failing to
>> use PPS at all (ignoring the strange behavior that we're still trying
>> to solve).
>>
>> In ntp-dev p239 (which was my previous version), the PPS signal would
>> lock on and start disciplining the clock after the time stabilized
>> (marked with the 'o' in the first column). This would happen typically
>> within an hour of starting ntpd assuming the clock was reasonably
>> close (e.g. set by ntpdate or using ntpd -g) However, in the more
>> recent version p256, PPS never achieves this state. It is forever now
>> marked as a false ticker even at the very beginning of operation.
>>
>> Here is the status after eight hours:
>>> remote refid st t when poll reach delay offset jitter
>>> ==============================================================================
>>>
>>> x127.127.22.0 .PPS. 0 l 7 16 377 0.000 1.304 0.122
>>> 127.127.28.0 .GPSD. 4 l 38 128 377 0.000 -33.864 8.600
>>> +46.166.138.172 198.60.22.240 2 u 962 1024 377 53.932 0.228 0.579
>>> *64.73.32.134 209.51.161.238 2 u 554 1024 377 91.756 1.032 0.813
>>> -38.229.71.1 172.16.65.22 2 u 28 1024 377 81.924 5.867 0.788
>>> -130.207.165.28 130.207.244.240 2 u 109 1024 377 81.992 2.934 38.742
>>> +131.144.4.10 130.207.244.240 2 u 864 1024 377 87.036 1.739 1.365
>>
>> The jitter hasn't moved from that spot and the offset has hovered near
>> 1 ms the entire time. It's also not been freed from it falseticker
>> jail even when the numbers are sane.
>
> They are not sane.
>
> 127.127.22.0 PPS is too far out
> 127.127.28.0 GPSD is too far out
>
> You might want to try adding 'tos mindist 0.05' to ntp.conf
>
> I still have 'tos mindist 0.5' as my GPS NMEA output
> was varying too much.
>
>
> Remind me as to why you are using GPSD?
>
>
> David

Note that in the above case the SHM refclock is set to noselect so it is 
playing no part at all in this process.  It has been this way for a 
while.  I'll enable that later on when the PPS part of everything works 
properly.

I'm using GPSD because I need the data from the GPS receiver available 
only in SiRF binary mode that isn't available in NMEA mode.  But again, 
that's moot in this case because the refclock is noselect.  Only PPS is 
enabled.


More information about the questions mailing list