On 2/11/2012 07:08, Dave Hart wrote:
On Sat, Feb 11, 2012 at 09:42, A C<[email protected]> 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.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
