You will notice that the two peer listings for ntp2.npl.co.uk show that
it has changed its mind in the space of a few minutes.
To me this says that their public NTP server is thrashing. I believe
had the same problem with my ntpd server initially. I believe that it
is caused when you are synching to two different machines that each
derive their time from the same source. I had four stratum one entries
in my config list; two at Melbourne University, and two at the CSIRO
National Measurement Laboratory. At Melbourne University each server
was synched to a GPS receiver, while at CSIRO each was synched to their
atomic clock. Typically CSIRO wasn't in the picture because their delay
was always at least 30ms, whicle Melbourne University is less than 20.
That meant my stratum two server was normally trying to choose between
two servers that were in turn deriving their time from a single time
source. Effectively I had the same setup as ntp2.npl.co.uk.
With this setup I was noticing that my poll period was very short,
typically 64 or lower, my server was constantly flicking between the two
servers at Melbourne University, and my server was slewing the clock all
around the place. As soon as I took out the redundant time server at
each place I got sanity again. Now my poll time is typically 128 or 256
and it rarely changes its time source.
>From my non-technical perspective I have a fuzzy idea of how this could
come about. With a single time source being filtered through two
different machines you will get two different times that are extremely
close but always different. With such a line-ball situation it's easy
to imagine that the ntpd server could easily be "convinced" to change
its mind about which of the two would be a better peer.
Paul Norris
IT Manager
DataSend Australia Pty Ltd
[EMAIL PROTECTED]
Ph: (03) 9558 1199
Fax: (03) 9558 1399
>>> Niek <[EMAIL PROTECTED]> 01/31/06 5:20 AM >>>
On 1/30/2006 7:12 PM +0100, Simon Arlott wrote:
> The frequency status variable is ridiculously high:
Maybe becasue something is funky elsewhere (check reach):
[EMAIL PROTECTED]:~# ntpq -p ntp2.npl.co.uk
remote refid st t when poll reach delay offset
jitter
==============================================================================
LOCAL(0) .GPS. 0 - - 64 0 0.000 0.000
0.000
+139.143.49.13 .1PPS. 1 - 8 64 7 9.275 -6.556
5.353
*139.143.49.18 .1PPS. 1 - 16 64 7 9.275 -6.899
5.633
Few mins later:
[EMAIL PROTECTED]:~# ntpq -p ntp2.npl.co.uk
remote refid st t when poll reach delay offset
jitter
==============================================================================
LOCAL(0) .GPS. 0 - - 64 0 0.000 0.000
0.000
*139.143.49.13 .1PPS. 1 - 7 64 3 9.275 -3.442
0.551
+139.143.49.18 .1PPS. 1 - 20 64 1 9.274 -3.232
0.000
Niek Baakman
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
