[ntp:questions] ntpd wedged again
David Lord
snews at lordynet.org
Sun Feb 12 06:22:13 UTC 2012
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
>
>
> Another interesting note is that under p239 the jitter was almost always
> 0.061 when everything was stable. Now the jitter is twice that but
> there hasn't been any change to the hardware or the OS, just ntpd.
More information about the questions
mailing list