RE: [chrony-users] Multiple interfaces is possible? |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
Hi Miroslav,
Thanks for the reply.
My second question about limiting samples is nothing to do with the bug.
Question <1>
Let me put the question in other way. chronyd accepts "n" number of samples before it actually updates the time. How can this "n" be configured? How does chronyd decides upon how many samples it needs to come to conclusion
that the source data is authentic and system time should be set?
My assumption is makestep is one of the configuration that can make chronyd jump to the expected time. I have used "makestep 1000 -1" in the configuration so that there should not be gradual change as system time could be set to epoch. But still chronyd takes in many samples (approx 35) to set the system time.
Question <2>
With the workaround I am able to feed data from multiple sources. Please consider below logs for my question below:
1970-01-01T00:00:04Z chronyd version DEVELOPMENT starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP -SCFILTER -SECHASH +ASYNCDNS +IPV6 -DEBUG)
1970-01-01T00:00:04Z commandkey directive is no longer supported
1970-01-01T00:00:04Z Could not open keyfile /etc/chrony/chrony.keys
1970-01-01T00:00:04Z Frequency 0.000 +/- 1000000.000 ppm read from /var/log/chrony/chrony.drift
1970-01-01T00:00:52Z Selected source SOC2
1970-01-01T00:00:52Z System clock wrong by 1609373625.736444 seconds, adjustment started
2020-12-31T00:14:38Z System clock was stepped by 1609373625.736444 seconds
2020-12-31T00:14:54Z Can't synchronise: no majority
What does this mean? "Can't synchronise: no majority".
--
Thanks and Regards,
Bhushan J.
-----Original Message-----
From: Miroslav Lichvar [mailto:mlichvar@xxxxxxxxxx]
Sent: Wednesday, May 11, 2016 2:14 PM
To: chrony-users@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [chrony-users] Multiple interfaces is possible?
On Wed, May 11, 2016 at 07:01:17AM +0000, Jahagirdar, Bhushan wrote:
> Attached strace log and config file that I am using.
> Chrony version I tried: 2.2.1
Thanks. In the log chronyd is trying to read the SOCK sample from a wrong file descriptor. That fails, select() returns that there are still data waiting on the right descriptor, chronyd tries to read from the wrong descriptor again, and this runs in an infinite loop.
It looks like the problem is with the reallocation of the first SOCK refclock instance. When the second SOCK instance is added, the pointer that the scheduler is using for the first instance becomes invalid.
This bug was apparently introduced in 2.0.
I'm not sure what's the best way to fix it yet. As a workaround you can add two more refclocks before the real refclocks to prevent chronyd from reallocating the third refclock instance. E.g.
refclock SOCK /var/run/chrony/chrony.dummy1.sock
refclock SOCK /var/run/chrony/chrony.dummy2.sock
refclock SOCK /var/run/chrony/chrony.ttyS1.sock refclock SOCK /var/run/chrony/chrony.ttyS2.sock
> --------------------------------
>
> Also, I would like to know how can the minimum sampling limit be set for chronyd?
> I am using makestep as below with the assumption that system is set to epoch.
> makestep 1000 -1
>
> Still the number of samples being analyzed are many. How to reduce this?
I'm not sure which samples do you want to limit. Is this related to the bug described above which causes an infinite loop?
--
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.