[ntp:questions] ntpd wedged again

A C agcarver+ntp at acarver.net
Sun Feb 12 04:39:41 UTC 2012


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.


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