f



Possible reasons for not switching back to a real time source?

So, matters of having configured just one "real" source, and having
configured a LOCAL fallback aside, can someone posit on some reasons
why ntpd might stick with LOCAL even when a "real" time source is
(once again?) reachable?

$ sudo ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ntp.ab.cde      1.2.3.4          2 u   40   64  377   48.919    0.485   0.415
*LOCAL(0)        .LOCL.          10 l   27   64  377    0.000    0.000   0.000

I do not have access ot the syslog, just that bit of ntpq -p output
n-th hand. (I can try to ask for some though if something would have
been logged there)

My current wild guess is that "ntp.ab.cde" was unreachable for a
while, so ntpd switched to the LOCAL source.  What I don't understand
though is why it wouldn't have switched back to the real time source
once it was reachable again.

The ntp version is 1:4.2.6.p5+dfsg-7+deb8u1

thanks,

rick jones
-- 
"You can't do a damn thing in this house without having to do three
other things first!" - my father (It seems universally applicable :)
these opinions are mine, all mine; HPE might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hpe.com but NOT BOTH...
0
Rick
12/2/2016 6:22:34 PM
comp.protocols.time.ntp 4895 articles. 2 followers. Post Follow

3 Replies
131 Views

Similar Articles

[PageSpeed] 53

On 02/12/16 18:22, Rick Jones wrote:
> So, matters of having configured just one "real" source, and having
> configured a LOCAL fallback aside, can someone posit on some reasons
> why ntpd might stick with LOCAL even when a "real" time source is
> (once again?) reachable?
>
> $ sudo ntpq -p
> =E2=80=82=E2=80=82=E2=80=82=E2=80=82 remote=E2=80=82=E2=80=82=E2=80=82=E2=
=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82 refid=E2=80=82=
=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82st t when poll reach=E2=80=82=
=E2=80=82 delay=E2=80=82=E2=80=82 offset=E2=80=82=E2=80=82jitter
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
> +ntp.ab.cde=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=821.2.3.=
4=E2=80=82      =E2=80=82=E2=80=82=E2=80=822 u=E2=80=82=E2=80=82 40=E2=80=
=82=E2=80=82 64=E2=80=82=E2=80=82377=E2=80=82=E2=80=82 48.919=E2=80=82=E2=
=80=82=E2=80=82=E2=80=820.485=E2=80=82=E2=80=82 0.415
> *LOCAL(0)=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=
=E2=80=82.LOCL.=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=
=82=E2=80=82=E2=80=82=E2=80=8210 l=E2=80=82=E2=80=82 27=E2=80=82=E2=80=82=
 64=E2=80=82=E2=80=82377=E2=80=82=E2=80=82=E2=80=82=E2=80=820.000=E2=80=82=
=E2=80=82=E2=80=82=E2=80=820.000=E2=80=82=E2=80=82 0.000

There are two incompatible cliques.  You need at least two real sources, =

so that they can establish a set of mutually compatible clocks (all=20
times lie within each other's error bounds).

Why do you have LOCL at all.  It should never be used on pure clients,=20
and orphan mode is generally better on servers.

0
David
12/2/2016 8:22:22 PM
David Woolley <david@ex.djwhome.demon.invalid> wrote:
> There are two incompatible cliques.  You need at least two real
> sources, so that they can establish a set of mutually compatible
> clocks (all times lie within each other's error bounds).

So the one "real" clock being at stratum 2 rather than 10 wouldn't be
enough to cause sync to switch back to it once reachable?

> Why do you have LOCL at all.  It should never be used on pure
> clients, and orphan mode is generally better on servers.

It is "just the way things were done" for that environment.  That old
song and dance.  I will convey the suggestion to use orphan mode.

thanks,

rick jones
-- 
Process shall set you free from the need for rational thought. 
these opinions are mine, all mine; HPE might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hpe.com but NOT BOTH...
0
Rick
12/2/2016 8:53:20 PM
On 2016-12-02, Rick Jones <rick.jones2@hpe.com> wrote:
> David Woolley <david@ex.djwhome.demon.invalid> wrote:
>> There are two incompatible cliques.  You need at least two real
>> sources, so that they can establish a set of mutually compatible
>> clocks (all times lie within each other's error bounds).
>
> So the one "real" clock being at stratum 2 rather than 10 wouldn't be
> enough to cause sync to switch back to it once reachable?
>
>> Why do you have LOCL at all.  It should never be used on pure
>> clients, and orphan mode is generally better on servers.
>
> It is "just the way things were done" for that environment.  That old
> song and dance.  I will convey the suggestion to use orphan mode.

Yes, egged on by incompetents at verious distributions who advocate and
advocated LOCAL mode for some bizarre reasons.

Anyway, just get rid of the local mode.


>
> thanks,
>
> rick jones
0
William
12/2/2016 10:17:56 PM
Reply: