RE: [chrony-users] Can't synchronise: no majority

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

On Thu, 26 Mar 2020, Niko Delarich wrote:

> Thank you all for your responses!
>
> I agree that adding a third server or disabling the bad server is probably the best way to fix this but I'm not sure our customer will like this answer since NTP apparently works correctly on a lot of other devices in their network and it even worked with our devices before we switched from openntp to chrony...

There is no way that ntpd could work correctly in this situation. The advice
in ntpd is exactly the same advice that we have given you-- use three servers
at least. It may be that chrony is slightly more sensitive to disagreements in
time (deciding whether the uncertainties overlap or not) but ntpd will also
not be able to choose a server if the servers give time that is too far apart(
where too far apart is determined by the uncertainties of each of the time
sources, just as in chrony). Just because a server has a smaller uncertainty
does not mean that it is not the "crazy" time server. It might very stably be
delivering the time at .9 sec/sec.

> I'm going to try to patch the source code to make chrony choose the better server (based on score) in the "no majority" case.

You are of course free to do whatever you want, but that change is not a good
idea. I would suspect that educating the users as to why there should be at
least 3 independent servers is a better idea (and yes, you screwed up when you
originally distributed your timing solution by not doing so. They trusted you
and paid you to give them a "best practice" solution. You didn't. And now you
are kludging your way around that problem.)

Now, IF you can show that there is a problem in the way that chrony calculates
the overlap between the two sources, then people will listen.
> Thanks again!
>
> Niko
>
> > -----Original Message-----
> > From: Miroslav Lichvar <mlichvar@xxxxxxxxxx>
> > Sent: Mittwoch, 25. März 2020 14:39
> > To: chrony-users@xxxxxxxxxxxxxxxxxxxx
> > Subject: Re: [chrony-users] Can't synchronise: no majority
> >
> > On Wed, Mar 25, 2020 at 01:22:11PM +0000, Niko Delarich wrote:
> > > I know the situation is not ideal and the customer should probably just use
> > better servers but shouldn't chrony just pick the "better" of the two servers
> > in this case (#2 with stratum 3)?
> > > There's a comment in sources.c:869 which seems to indicate it should:
> > >   The first case is just bad luck - we need extra sources to
> > >   detect the falseticker, so just make an arbitrary choice based
> > >   on stratum & stability etc.
> >
> > If I understand that comment correctly, it is for the example with three
> > servers, where two and two agree with one another, so that's a different
> > case, and the "arbitrary choice" is for selecting the system peer, not a
> > falseticker.
> >
> > > Or is there maybe a configuration option I'm missing? Setting one of the
> > sources to "trusted" manually is most likely not an option for us since the
> > servers may be assigned by a DHCP server.
> >
> > No, I don't think there is a non-source option that would force chronyd to
> > select a source in this case.
> >
> > They should disable the bad server.
> >
> > --
> > Miroslav Lichvar
> >
> >
> > --
> > To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
> > with "unsubscribe" in the subject.
> > For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
> > with "help" in the subject.
> > Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.
>
>
> --
> To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
> with "unsubscribe" in the subject.
> For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
> with "help" in the subject.
> Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.