[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