Re: [chrony-users] Multiple interfaces is possible?
On Wed, Sep 14, 2016 at 11:49:02AM +, Jahagirdar, Bhushan wrote: > From your reply below it seems to me that at least 48 sec would be > needed for Chrony to lock on a source and set the time for that one > source. If there are multiple sources then it would be multiple of > 48 sec? No, the sources are polled in parallel. If they are all configured with the same polling interval, the time needed to make the first update of clock after start wouldn't change. > What if there is stringent requirement that the time should be set within 1-2 > secs in a typical embedded system. > Then is there any specific configuration that can help achieve this with > Chrony? You can shorten the refclock polling interval (the poll option) to reduce the time as needed. But 1-2 seconds will be possible only if the SOCK refclock can make multiple measurements per second. With 1 measurement per second the best you can do is 3 seconds (poll 0). Note that if there is only one measurement per poll, the median filter will be effectively disabled and the synchronization will be very sensitive to errors in the measurements. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
RE: [chrony-users] Multiple interfaces is possible?
Hi Mirsolav, >From your reply below it seems to me that at least 48 sec would be needed for >Chrony to lock on a source and set the time for that one source. If there are >multiple sources then it would be multiple of 48 sec? What if there is >stringent requirement that the time should be set within 1-2 secs in a typical >embedded system. Then is there any specific configuration that can help achieve this with Chrony? Thanks and Regards, Bhushan J. -Original Message- From: Bill Unruh [mailto:un...@physics.ubc.ca] Sent: Thursday, May 12, 2016 6:55 PM To: chrony-users@chrony.tuxfamily.org Subject: RE: [chrony-users] Multiple interfaces is possible? On Wed, 11 May 2016, Jahagirdar, Bhushan wrote: > 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 Chrony does a least squares fit to the data to determine the offset and rate. Thus it needs at least 3 samples to do that. It tests whether the a linear fit is a reasonable approximation (by looking at the number of changes in sign of the difference of the measured offsets from the fit line seem to be randomly distributed) and if not, it reduces the number of samples (thowing out the old ones). Thus in the ideal case the number of samples used will grow to a max of something like 64.This reduces the variance. > that the source data is authentic and system time should be set? 3. But chrony does not step the clock. It slews it, rapidly if necessary. makestep introduces the danger of back steps which can have very bad effects on the filesystem. > 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. > chrony for the PPS gets one sample for every 16PPS samples (poll of 4) throwing out about 40% of the samples which are furthest from the median to stop "popcorn" erors from causing trouble. Thus it will take about 48 PPS samples to collect the 3 inputs needed. I do not know if you can reduce the poll to less than 4 (16 sec) > 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 +/- > 100.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". chrony looks at the various sources to see if they agree about what the time is. With 2 sources, it is really hard to get a majority. 1 or 3 sources are needed (3 to outvote one bad source) > > -- > Thanks and Regards, > Bhushan J. > > -----Original Message- > From: Miroslav Lichvar [mailto:mlich...@redhat.com] > Sent: Wednesday, May 11, 2016 2:14 PM > To: chrony-users@chrony.tuxfamily.org > Subject: Re: [chrony-users] Multiple interfaces is possible? > > On Wed, May 11, 2016 at 07:01:17AM +, 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. &g
RE: [chrony-users] Multiple interfaces is possible?
On Wed, 11 May 2016, Jahagirdar, Bhushan wrote: 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 Chrony does a least squares fit to the data to determine the offset and rate. Thus it needs at least 3 samples to do that. It tests whether the a linear fit is a reasonable approximation (by looking at the number of changes in sign of the difference of the measured offsets from the fit line seem to be randomly distributed) and if not, it reduces the number of samples (thowing out the old ones). Thus in the ideal case the number of samples used will grow to a max of something like 64.This reduces the variance. that the source data is authentic and system time should be set? 3. But chrony does not step the clock. It slews it, rapidly if necessary. makestep introduces the danger of back steps which can have very bad effects on the filesystem. 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. chrony for the PPS gets one sample for every 16PPS samples (poll of 4) throwing out about 40% of the samples which are furthest from the median to stop "popcorn" erors from causing trouble. Thus it will take about 48 PPS samples to collect the 3 inputs needed. I do not know if you can reduce the poll to less than 4 (16 sec) 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 +/- 100.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". chrony looks at the various sources to see if they agree about what the time is. With 2 sources, it is really hard to get a majority. 1 or 3 sources are needed (3 to outvote one bad source) -- Thanks and Regards, Bhushan J. -Original Message- From: Miroslav Lichvar [mailto:mlich...@redhat.com] Sent: Wednesday, May 11, 2016 2:14 PM To: chrony-users@chrony.tuxfamily.org Subject: Re: [chrony-users] Multiple interfaces is possible? On Wed, May 11, 2016 at 07:01:17AM +, 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-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org. -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the
Re: [chrony-users] Multiple interfaces is possible?
On Wed, May 11, 2016 at 07:01:17AM +, 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-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
RE: [chrony-users] Multiple interfaces is possible?
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 +/- 100.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:mlich...@redhat.com] Sent: Wednesday, May 11, 2016 2:14 PM To: chrony-users@chrony.tuxfamily.org Subject: Re: [chrony-users] Multiple interfaces is possible? On Wed, May 11, 2016 at 07:01:17AM +, 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-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org. -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Multiple interfaces is possible?
On Tue, May 10, 2016 at 10:06:40AM +, Jahagirdar, Bhushan wrote: > Hi Miroslav, > > I tried using below SOCK configuration in chrony.conf file in order to feed > multiple time source data to chronyd. > refclock SOCK /var/run/chrony.ttyS1.sock > refclock SOCK /var/run/chrony.ttyS2.sock > > With this the first socket becomes invalid and second remains as valid socket. > As per your mail below this is supposed to work. > > So I am getting the error: > 2015-10-14T13:03:56Z Could not read SOCK sample : Socket operation on > non-socket > > chronyd version I am using is 2.2 I just tried configuration with two SOCK refclocks and it seems to be working. Could you try running chronyd in strace, wait for this error, and send me the output? -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] Multiple interfaces is possible?
On Wed, Dec 30, 2015 at 08:48:39AM +, Jahagirdar, Bhushan wrote: > I want to feed time data from multiple sources to chronyd. > How can I support this with the current interfaces that chronyd provides? > Can I generate multiple SOCK interfaces for every source ? What are the > limitations in doing this? You can feed chronyd with data from multiple refclocks, but each source should have its own socket, so chronyd can filter their samples properly, compare the sources, discard falsetickers, etc. For example: refclock SOCK /var/run/chrony/refclock.1.sock refclock SOCK /var/run/chrony/refclock.2.sock refclock SOCK /var/run/chrony/refclock.3.sock If the sources don't agree exactly with each other, you may need to increase their assumed delay with the delay option (1 nanosecond by default), so their intervals overlap and pass the source selection. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
